Tweet
There are basically three ways I could begin working on the PS2-side GUI.
First, I could simply use the (hacky) scr_printf function included in the PS2SDK. This would keep the GUI fairly limited, and very primitive looking, but would be the easiest way of doing things. Perhaps I'll start this way, while I build the basic menu structure.
Second, I could utilize the GS to draw fonts, or use something like BMP2C to convert bitmap fonts to raw C, and throw them around the screen in the right places. This is probably the way we'll eventually end up doing things, and is, as a purist might say, the "right" way to do it. However, this may be considerable work, if we're to have an original font, and a functional menu system that highlights/underlines/etc the selected item(s).
Third, I could look into FONTM, something documented by [RO]man and adresd. Apparently, there is a built-in PS2 font in OSDSYS, but there are three possible issues with following this route: the font is probably about as primitive as the scr_printf one, there may be legal issues with loading FONTM, as it's likely Sony intellectual property, and it's rumored that it may not exist, or may be different, on a few PS2 models (though it has been tested on several models, and no one's verified a failure as far as I can see). Anyway, here's what I have on it (I forget where I grabbed this from, a year or so ago):
_____________________________________________
The following is ANSI C (compile using DevCPP or some other C compiler, not PS2SDK):
_________________________________________________
Any thoughts or suggestions?
First, I could simply use the (hacky) scr_printf function included in the PS2SDK. This would keep the GUI fairly limited, and very primitive looking, but would be the easiest way of doing things. Perhaps I'll start this way, while I build the basic menu structure.
Second, I could utilize the GS to draw fonts, or use something like BMP2C to convert bitmap fonts to raw C, and throw them around the screen in the right places. This is probably the way we'll eventually end up doing things, and is, as a purist might say, the "right" way to do it. However, this may be considerable work, if we're to have an original font, and a functional menu system that highlights/underlines/etc the selected item(s).
Third, I could look into FONTM, something documented by [RO]man and adresd. Apparently, there is a built-in PS2 font in OSDSYS, but there are three possible issues with following this route: the font is probably about as primitive as the scr_printf one, there may be legal issues with loading FONTM, as it's likely Sony intellectual property, and it's rumored that it may not exist, or may be different, on a few PS2 models (though it has been tested on several models, and no one's verified a failure as far as I can see). Anyway, here's what I have on it (I forget where I grabbed this from, a year or so ago):
Description of file format for 'FONTM' from the PS2 BIOS.
---------------------------------------------------------
adresd 2003.
Intro
-----
The FONTM file contains a PS2 Font, in a format which allows access to individual characters without having to upload a big font bitmap. As each character is stored seperately.
The font contains over 4000 characters, of all types and languages, and non-textual characters as well.
This allows flexible use and the characters to be used any way in which the programmer wishes.
The FONTM file is packed, the depack algorithm and example code have been provided by [RO]man on the site: http://ps2dev.pgamers.com/ in the file 'unpack.zip'.
Rather than duplicate it here, grab from there.
[Quick greet to [RO]man and the good work he has done
]
This should be used to depack the file before trying to use the supplied extractor test program, or using it as reference to this document.
After hearing many people wonder about the format of these files and using them, as they quite like the fonts, I decided to write this short doc and example code.
I hope this is of some use to someone.
The fonts in the files I examined were all 4bit CLUT.
The CLUT does not seem to be included in here, and is probably elsewhere.
That does not matter too much as it seems an intensity based CLUT, so creating one will not be hard.
One thing to note, it has been pointed out that this file may not be consistent across ALL ps2 models, and may be a different format or missing on some models.
I do not have details of this, but until it is verified take this into consideration.
I've tested it on my SCPH-10000 (japanese) and SCPH-30003R (pal) machines.
It's also been tested on a SCPH-50000 (japanese) and SCPH-35001 (US).
Data Format
-----------
In this doc, uint32 means: 4 bytes, A,B,C,D
value = (A) + (B<<8) + (C<<16) + (D<<24)
The file contains a basic header
--------------------------------
4 ascii bytes 'FBJ2'
4 bytes, uint32, version
4 bytes, uint32, bitsize of file
4 bytes, uint32, baseoffset
4 bytes, uint32, num entries in the file
4 bytes, uint32, end of file position
Then follows the offset table
-----------------------------
Each entry is 4 bytes (uint32), making up an offset.
Take this offset add this to the baseoffset from the header, this gives the absolute offset in the file.
There are 'num entries' offsets in a list.
The size of each entry can be taken from the difference between offsets, and seems to be the same for all entries in the file. So calculate difference between first and second entries, and that will give the size.
Then follows the actual data for each character
-----------------------------------------------
This is 4bit CLUT data.
A line of the font graphic is 13 bytes.
each byte represents two pixels, so for 0x43 pixel 1 is color 4, pixel 2 is color 3.
This means each pixel can have one of 16 values, 0x0 -> 0xf
An example of a character is given below (NOTE:this is not from the actual file, but a madeup one).
This is shown in HEX notation, as it makes it really easy to view.
----
00000000000000000000000000
01111111111111111111111110
01200000000000000000000310
01020000000000000000003010
01002000000000000000030010
01000200000000000000300010
01000020000000000003000010
01000002000000000030000010
01000000200000000300000010
01000000020000003000000010
01000000002FFFF30000000010
0100000000F2EE3F0000000010
01FFFFFFFFFE23EFFFFFFFFF10
01FFFFFFFFFE32EFFFFFFFFF10
0100000000F3EE2F0000000010
01000000003FFFF20000000010
01000000030000002000000010
01000000300000000200000010
01000003000000000020000010
01000030000000000002000010
01000300000000000000200010
01003000000000000000020010
01030000000000000000002010
01300000000000000000000210
01111111111111111111111110
00000000000000000000000000
The example exporter/dump program
---------------------------------
I have included a program, which will dump out the characters from the font file to a ascii version. You can set in the code which chars to dump out, or all of them.
The ascii output is easy to view and I wanted to keep the src clean and easy to understand.
I leave it as a simple exercise for the reader to write these out as bitmaps.
Or to use the same format for similar data, and create new fonts.
Thats all folks,
adresd
---------------------------------------------------------
adresd 2003.
Intro
-----
The FONTM file contains a PS2 Font, in a format which allows access to individual characters without having to upload a big font bitmap. As each character is stored seperately.
The font contains over 4000 characters, of all types and languages, and non-textual characters as well.
This allows flexible use and the characters to be used any way in which the programmer wishes.
The FONTM file is packed, the depack algorithm and example code have been provided by [RO]man on the site: http://ps2dev.pgamers.com/ in the file 'unpack.zip'.
Rather than duplicate it here, grab from there.
[Quick greet to [RO]man and the good work he has done
]This should be used to depack the file before trying to use the supplied extractor test program, or using it as reference to this document.
After hearing many people wonder about the format of these files and using them, as they quite like the fonts, I decided to write this short doc and example code.
I hope this is of some use to someone.
The fonts in the files I examined were all 4bit CLUT.
The CLUT does not seem to be included in here, and is probably elsewhere.
That does not matter too much as it seems an intensity based CLUT, so creating one will not be hard.
One thing to note, it has been pointed out that this file may not be consistent across ALL ps2 models, and may be a different format or missing on some models.
I do not have details of this, but until it is verified take this into consideration.
I've tested it on my SCPH-10000 (japanese) and SCPH-30003R (pal) machines.
It's also been tested on a SCPH-50000 (japanese) and SCPH-35001 (US).
Data Format
-----------
In this doc, uint32 means: 4 bytes, A,B,C,D
value = (A) + (B<<8) + (C<<16) + (D<<24)
The file contains a basic header
--------------------------------
4 ascii bytes 'FBJ2'
4 bytes, uint32, version
4 bytes, uint32, bitsize of file
4 bytes, uint32, baseoffset
4 bytes, uint32, num entries in the file
4 bytes, uint32, end of file position
Then follows the offset table
-----------------------------
Each entry is 4 bytes (uint32), making up an offset.
Take this offset add this to the baseoffset from the header, this gives the absolute offset in the file.
There are 'num entries' offsets in a list.
The size of each entry can be taken from the difference between offsets, and seems to be the same for all entries in the file. So calculate difference between first and second entries, and that will give the size.
Then follows the actual data for each character
-----------------------------------------------
This is 4bit CLUT data.
A line of the font graphic is 13 bytes.
each byte represents two pixels, so for 0x43 pixel 1 is color 4, pixel 2 is color 3.
This means each pixel can have one of 16 values, 0x0 -> 0xf
An example of a character is given below (NOTE:this is not from the actual file, but a madeup one).
This is shown in HEX notation, as it makes it really easy to view.
----
00000000000000000000000000
01111111111111111111111110
01200000000000000000000310
01020000000000000000003010
01002000000000000000030010
01000200000000000000300010
01000020000000000003000010
01000002000000000030000010
01000000200000000300000010
01000000020000003000000010
01000000002FFFF30000000010
0100000000F2EE3F0000000010
01FFFFFFFFFE23EFFFFFFFFF10
01FFFFFFFFFE32EFFFFFFFFF10
0100000000F3EE2F0000000010
01000000003FFFF20000000010
01000000030000002000000010
01000000300000000200000010
01000003000000000020000010
01000030000000000002000010
01000300000000000000200010
01003000000000000000020010
01030000000000000000002010
01300000000000000000000210
01111111111111111111111110
00000000000000000000000000
The example exporter/dump program
---------------------------------
I have included a program, which will dump out the characters from the font file to a ascii version. You can set in the code which chars to dump out, or all of them.
The ascii output is easy to view and I wanted to keep the src clean and easy to understand.
I leave it as a simple exercise for the reader to write these out as bitmaps.
Or to use the same format for similar data, and create new fonts.
Thats all folks,
adresd
The following is ANSI C (compile using DevCPP or some other C compiler, not PS2SDK):
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int offsets[10000];
unsigned int read_uint32(FILE *fp)
{
unsigned int address = fgetc(fp);
address += (fgetc(fp)<<8);
address += (fgetc(fp)<<16);
address += (fgetc(fp)<<24);
return (address);
}
// This is for output of the 13 byte wide, 4 bit clut format entries
// writes them out as a HEX display, so you can see what the chars are
void dump_chunk13(FILE *fp,int number)
{
int start, size, count;
FILE *fp2;
char filename[100];
start = offsets[number];
// Go to start of chunk
fseek(fp,start,SEEK_SET);
// work out size, by start of next chunk
size = offsets[number+1] - offsets[number];
sprintf(filename,"data_%04d.dat",number);
printf("dumping chunk13 - %d to '%s' (start %d , size %d)\n",number,filename,start,size);
fp2 = fopen(filename,"wb");
// Write out the chunk
for(count=0;count<size;count++)
{
fprintf(fp2,"%02X",fgetc(fp));
if (count%13 == 12) fprintf(fp2,"\n");
}
// Cleanup
fprintf(fp2,"\n");
fclose(fp2);
}
int main(int argc,char *argv[])
{
FILE *fp;
char data[100];
unsigned int address;
int count;
int maxcount;
int baseoffset;
if (argc == 2)
{
if ((fp = fopen(argv[1],"rb")) != 0)
{
fread(data,1,4,fp); // This reads the header bytes
data[4] = 0;
printf("Header : '%s'\n",data);
// Mini header first
address = read_uint32(fp); printf(" version : 0x%06X\n",address);
address = read_uint32(fp); printf(" bitsize : 0x%06X\n",address);
baseoffset = read_uint32(fp); printf(" baseoffset : 0x%06X\n",baseoffset);
maxcount = read_uint32(fp); printf(" num entries : 0x%06X\n",maxcount);
address = read_uint32(fp); printf(" end of file : 0x%06X\n",address);
printf("max entries = %d\n",maxcount);
// now read the offset entries
for (count=0;count<maxcount;count++)
{
offsets[count] = baseoffset + read_uint32(fp);
}
// dump a few example chunks to test
for (count=0;count<100;count++)
dump_chunk13(fp,count);
for (count=0;count<100;count++)
dump_chunk13(fp,4000+count);
fclose(fp);
}
} else printf("\nUsage : %s filename\n\n",argv[0]);
return 1;
}
Any thoughts or suggestions?
Comment