The above video goes away if you are a member and logged in, so log in now!
I've increased number of "discrete value" to 96, position is ok, drawing is ok, but i've got some problem with erase ( lot of black line on movie ).
@Bixente: you can use e-mail for questions/help, so we won't pollute the forum ...
@paulodeleo: finally I've managed to fiddle with VGA modes . 2 modes will be supported: 640x480@60Hz and 640x480@75Hz...
@EEUG: I've tried using the PAD.c you sent me - it works well, but only with rom0:PADMAN, not rom1:PADMAN or the PADMAN.IRX from the Sony DVD Player 2.10 disc. - perhaps i'm doing something wrong... Anyway, if you are using rom1:PADMAN + rom1:SIO2MAN, and get the pads to work, that's great because it'll be dead easy for me to integrate the remote control support code i've been testing, as that depends on rom1:SIO2MAN. I'll get to work on that after Christmas when the new version of SMS is in SVN.
@dave_t: I'll try this this stuff again with rom1 (maybe I also did something wrong (it was in August, I think, when I tried rom1 stuff)). Verify also that you've loaded SIO2MAN from rom1...
...those who wants to compile SMS version 1.5 have to update development environment (otherwise there will be linker error). I've updated download link (rapidshare.de again) on the first page of this thread (3rd post)...
I've lost this post! Thank's EEUG!
Originally Posted by EEUG
Thank's for the updated ps2dev again!
PS2 50001 V9 + Matrix Infinity + Maxtor 80Gb HDD = FUN!
I found a line of code ..found on Ps2 bios doucumentation that state.....ps2 bios contain an item call FontM..that will have all the font character that u need for all languages ...Perhaps subtitle option can direct feed from font of ps2 Bios.
Description of file format for 'FONTM' from the PS2 BIOS.
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).
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.
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,
@hip203: in previous versions of SMS where FONTM was used I also used this file . Here're my explanations: FONTM "file" contains exactly 4416 symbols (at least in my PS2). It does not contain "all symbols for all languages" (at least I didn't found there such a symbols like ÓĂçě etc.). Characters there are not arranged to conform any codepage (it's just a one big chunk of compressed bitmaps), so, it's necessary to create extra translation tables "by hand", which is almost impossible task for me in case of Chinese, Corean etc. languages. That's why "MTK font" solution was choosen. Next thing is MBCS. While it's possible to implement it, the amount of work is quite big. At the first place string manipulation functions (strcpy, strtok, sscanf etc.) from ps2sdk must be rewritten and tested. Then new symbol drawing routines should be implemented since all these "thousands" of eastern symbols won't fit in the GS memory (which is also required for images from movies). Then come subtitles themselves: file parsing routines, distinguishing between SBCS and MBCS files etc. should be reimplemented. It's just a boring work for me that will take huge amount of time. Time to establish "Eastern Subsidiary of SMS" to implement this and I'll provide any help I can. Thank you for understanding ...