I am trying to understand how specific script (fade function) works in PICO8:
function fade()
fadep=split("0xffff.8,0xfffe.8,0xffec.8,0xfec8.8,0xec80.8,0xc800.8,0x8000.8,0x0.8")
for i=0,64 do
fillp(fadep[flr(i/(32/#fadep))+1])
rectfill(0,0,127,127,0)
flip()
end
end
I understand that split() function splits the number in argument separated by comma (by default) and we will get 8 HEX numbers like first one "0xffff.8".
As far as I know HEX numbers starts with "0x", but what means this ".8" at the end?
Thanks!
In the function filp per the wiki
Alternatively, you can set the pattern to make the off bits transparent (showing what is drawn underneath). To do this, add 0b0.1, or 0x0.8 if using hex, to the pattern value
It explicitly sets the off bits to be transparent as explained in the fillp write up
The color parameter to the drawing functions (such as circfill()) can set two colors, to be used for the on bits (1's) and off bits (0's) of the pattern. The four lower bits of the color value are the "on" color, and the higher bits are the "off" color. For example, to draw the on bits as light blue (12, or 0xc) and the off bits as dark blue (1), set the color to 0x1c (28).
That's the fractional portion of a hex number. You can also use the fractional portion on the decimal and binary representations.
The notation is a bit odd, but thanks for asking that was a fun one to learn.
Related
I am receiving hex data from a serial port.
I have converted the hex data to corresponding int value.
I want to display the equivalent character over GTK label.
But if we see character map there are control characters from 0x00 to 0x20.
So i was thinking of adding 256 to the converted int value and show the corresponding Unicode character to label.
But i am not able to convert int to Unicode. say if i have an array of ints 266,267,289...
how should i convert it to Unichar and display over GTK label.
I know it may seems very basic problem to you all but i have struggled a lot and didn't find any answer. Please help,
The GTK functions that set text on UI elements all assume UTF-8 strings. A single unsigned byte representing a Unicode code point with value > 127 will not form a valid UTF-8 string if written out as an unsigned byte. I can think of a couple of ways around this.
Store the code point as a 32-bit integer (which is essentially UTF-32) and use the functions in the iconv library, or something similar, to do the conversion from UTF-32 to UTF-8. There are other conversion implementations in C widely available. Converting your unsigned byte to UTF-32 really amounts to padding it with three leading zero bytes -- which is easy to code.
Generate a UTF-8 string yourself, based on the 8-bit code point value. Since you have a limited range of values, this is easy-ish. If you look at the way that UTF-8 is written out, e.g., here:
https://en.wikipedia.org/wiki/UTF-8
you'll see that the values you need to represent are written as two unsigned bytes, the first beginning with binary 110B, and the second with 10B. The bits of the code point value are split up and distributed between these two bytes. Doing this conversion will need a little masking and bit-shifting, but it's not hugely difficult.
Having said all that, I have to wonder why you'd want to assign a character to a label that users will likely not understand? Why not just write the hex number on the label, if it is not a displayable character?
For the purpose of doing a project on character recognition, I found a database I could use as a training set. On the other hand, I am not able to understand the given format even though the below instructions were given with it. I could find no further help on how to figure this format out.
Fields 1-6 are separated by commas.
ID number of source article
2-byte symbol code (written in hexadecimal, using 4 bytes)
Character height of bitmap
Character width of bitmap
Bitmap image, where each 8-bit unit is written as a decimal from 0 to 255
Line feed
The link to the file(Google drive) for the database is attached below.
https://drive.google.com/file/d/0B-WsCQkhd_1iUUtJdHg0R1hfTHM/view?usp=sharing
It would be of great help if someone could figure out the way this format is presented. It is literally puzzling me.
Well, as far as I can understand this format every char description takes one line (until line feed sign).
ID number of source article
byte symbol code (written in hexadecimal, using 4 bytes)
Character height of bitmap
Character width of bitmap
Bitmap image, where each 8-bit unit is written as a decimal from 0 to 255 - and here the magic starts. Bitmap image is not only one comma separated value, but all values until you meet line feed. So it will be a lot of comma separated values that you can divide in rows using bitmap height and width values.
If you open this file in for example Notepad++ instead of stanart windows notepad, you will get a bit better view (turn on "Show all characters" to see line feed).
Hope it will help you.
I want to show some text in a 640*480 screen. Where can I get the codes for ASCII characters in RGB565 format for a C program, such that I can have a natural look-and-feel as a command-line terminal for such a screen.
1- What would be the best width-height for a character?
2- Where can I get the 16-bit hex code (known as Bitmap Font or Raster Font) for each character?
e.g. const unsigned short myChar[] = {0x0001, 0x0002, 0x0003, 0x0004 ...}
"... the 16-bit hex code ..." is a misconception. You must have meant 16 bytes – one byte (8 pixels) per character line. A 640*480 screen resolution with 'natural' sized text needs 8x16 bitmaps. That will show as 30 lines of 80 columns (the original MCGA screens actually showed only 25 lines, but that was with the equivalent of 640*400 – stretched a bit).
Basic Google-fu turns up this page: https://fossies.org/dox/X11Basic-1.23/8x16_8c_source.html, and the character set comes pretty close to as I remember it from ye olde monochrome monitors:a
................................................................
................................................................
................................................................
................................................................
...XXXX.........................................................
....XX..........................................................
....XX..........................................................
....XX...XXXXX..XX.XXX...XXX.XX.XX...XX..XXXX...XX.XXX...XXXXX..
....XX..XX...XX..XX..XX.XX..XX..XX...XX.....XX...XXX.XX.XX...XX.
....XX..XX...XX..XX..XX.XX..XX..XX.X.XX..XXXXX...XX..XX.XXXXXXX.
XX..XX..XX...XX..XX..XX.XX..XX..XX.X.XX.XX..XX...XX.....XX......
XX..XX..XX...XX..XX..XX..XXXXX..XXXXXXX.XX..XX...XX.....XX...XX.
.XXXX....XXXXX...XX..XX.....XX...XX.XX...XXX.XX.XXXX.....XXXXX..
........................XX..XX..................................
.........................XXXX...................................
................................................................
Since this is a simple monochrome bitmap pattern, you don't need "RGB565 format for a C program" (another misconception). It is way easier to loop over each bitmap and use your local equivalent of PutPixel to draw each character in any color you want. You can choose between not drawing the background (the 0 pixels) at all, or having a "background color". The space at the bottom of the bitmap is large enough to put in an underline.
That said: I've used such bitmaps for years but I recently switched to a fully antialiased gray shade format. The bitmaps are thus larger (a byte per pixel instead of a single bit) but you don't have to loop over individual bits anymore, which is a huge plus. Another is, I now can use the shades of gray as they are (thus drawing 'opaque') or treat them as alpha, and get nicely antialiased text in any color and over any background.
That looks like this:
I did not draw this font; I liked the way it looked on my terminal, so I wrote a C program to dump a basic character set and grabbed a copy of the screen. Then I converted the image to pure grayscale and wrote a quick-and-dirty program to convert the raw data into a proper C structure.
a Not entirely true. The font blitter in the MCGA video card added another column at the right of each character, so effectively the text was 9x16 pixels. For the small set of border graphics – ╔╦╤╕╩ and so on –, the extra column got copied from the rightmost one.
No the most elegant solution, but I created a bmp empty image and filled it with characters.
Then I used This tool to convert the bmp file to the C bitmap array.
You should then be able to distinguish the characters in your array.
If you can access some type of 16 bit dos mode, you might be able to get the fonts from a BIOS INT 10 (hex 10) call. In this example, the address of the font table is returned in es:bp (es is usually 0xc000). This works for 16 bit programs in Windows dos console mode on 32 bit versions of Windows. For 64 bit versions of Windows, DOSBOX may work, or using a virtual PC should also work. If this doesn't work, do a web search for "8 by 16 font", which should get you some example fonts.
INT 10 - VIDEO - GET FONT INFORMATION (EGA, MCGA, VGA)
AX = 1130h
BH = pointer specifier
00h INT 1Fh pointer
01h INT 43h pointer
02h ROM 8x14 character font pointer
03h ROM 8x8 double dot font pointer
04h ROM 8x8 double dot font (high 128 characters)
05h ROM alpha alternate (9 by 14) pointer (EGA,VGA)
06h ROM 8x16 font (MCGA, VGA)
07h ROM alternate 9x16 font (VGA only) (see #0020)
11h (UltraVision v2+) 8x20 font (VGA) or 8x19 font (autosync EGA)
12h (UltraVision v2+) 8x10 font (VGA) or 8x11 font (autosync EGA)
Return: ES:BP = specified pointer
CX = bytes/character of on-screen font (not the requested font!)
DL = highest character row on screen
Note: for UltraVision v2+, the 9xN alternate fonts follow the corresponding
8xN font at ES:BP+256N
BUG: the IBM EGA and some other EGA cards return in DL the number of rows on
screen rather than the highest row number (which is one less).
SeeAlso: AX=1100h,AX=1103h,AX=1120h,INT 1F"SYSTEM DATA",INT 43"VIDEO DATA"
I have this function in xilinx for giving output to Seven segment.
int result;
XIo_Out32(XPAR_SSG_DECODER_0_BASEADDR, result);
The function gets the int result and puts the output to seven segment as a hex value. So basicly, if i give result = 11; I would see A as a result in seven segment. To see a decimal value on sseg, one approach is to change the verilog code behind this and change the whole concept of the sseg. Another approach is to write a function that changes decimal value into a hex value. I've been searching for a good code block for this but it seems that every one of them, prints the values digit by digit with a loop. I need the whole value as a block. Unfortunately i cannot use the C++ libraries so i have primitive C code. Is there any known algorithms for converting?
Apparently, you want to convert symbol codes from ASCII to the ones from the 7-segment display character set. If so, you may create a simple mapping, maybe an array of codes indexed by ASCII character id. Then, you'll be able to call your function like:
XIo_Out32(XPAR_SSG_DECODER_0_BASEADDR, 'A');
Be careful to implement the mapping table for the whole ASCII range.
EDIT
Sorry, I've got your question wrong. You'll have to manually convert hexadecimal number to an array of decimal symbols. You may do it by dividing your number by increasing powers of 10 (10^0, 10^1, 10^2, etc) and thus get an array of remainders, which is a decimal representation of your number. You may use snprintf as H2CO3 recommends, but I would recommend against it in some of the embedded applications where RAM is limited; you may even be unable to use sprintf-like functions at all.
In some functional specs I'm reading they are talking about a numeric format with a 9(7)V9T presentation.
-How do I interprete this kind of format notations?
-How is this type physically stored in a flatfile (e.g. numeric?, signs? separators?)
Thank you for your wise answers!
A COBOL PICTURE string, such as 9(7)V9T specifies the general characteristics and editing requirements of an elementary
data item. A 9 represents a decimal digit, the (7) is a repetition factor for the preceding character. In this case
a 9. The V is an implied decimal point. This is all standard COBOL. So far we have an 8 digit decimal number with
an implied decimal point between the 7th and 8th digits.
The T is a bit of a curve ball. I have never
actually come across it before. However,
I Goolged up this reference.
It states that a T in a PICTURE string "... indicates that a display numeric field should only insert the sign into the upper
half of the last byte if the value is negative". Unfortunately, the author doesn't provide a reference so I can't
give you the source of this convention.
A COBOL picture of PIC S9(7)V9 USAGE DISPLAY on an IBM platform conforms to the 9(7)V9T description you have. This
data item
takes 8 bytes to represent. Each of the 8 digits are represented in the low 4 bits of each byte with the sign
recorded in the upper 4 bits of the low order byte. This just happens to be the way IBM choose to implement zoned-decimal.
Using a 9(7)V9T representation makes the representation explicit.
An alternative to the other answers is that the T is a character to be displayed or printed after the numeric value to represent a specific state, similar to use of CR for credit value or a trailing '-' to indicate a negative value.