DISCLAIMER
GSM IS DISTRIBUTED "AS IS". NO WARRANTY OF ANY KIND IS EXPRESSED OR IMPLIED. YOU USE AT YOUR OWN RISK. THE AUTHORS, WILL NOT BE LIABLE FOR DATA LOSS, DAMAGES, LOSS OF PROFITS OR ANY OTHER KIND OF LOSS OR DAMAGES WHILE USING OR MISUSING THIS SOFTWARE.
Welcome to the Graphics Synthesizer Mode Selector (aka: GSM) Project
Don't you have any idea what GSM is about? Please read the next posts (we try consolitate info on them).
Here you can get GSM public releases (by doctorxyz and dlanor).
STATUS
Early beta testing stage!
GSModeSelector releases by doctorxyz and dlanor (at psx-scene)
GSModeSelector v0.23x(2010.06.30) by doctorxyz and dlanor (compiled by dlanor)
- Modified the access trap mask to trap GS registers for all kernel segments
- Modified DisplayHandler to use kseg1 addresses for writing GS registers
GSModeSelector v0.23v(2010.06.10) by doctorxyz and dlanor (compiled by dlanor)
- Implemented two PAL60 modes, one interlaced and the other non-interlaced
- Fixed a bug preventing exit mode "PS2 Browser" from being loaded from CNF file
GSModeSelector v0.23u(2010.01.07) by doctorxyz and dlanor (compiled by dlanor)
- Reimplemented same changes (appx) as for my v0.23t beta, which were reverted in doctorxyz's v0.23s3 beta
- Changed drawing method for bottom border of GUI rectangle (still very imperfect)
- Added Timer_delay() function to control gsKit call timing (1 ms resolution)
- Added 'volatile' declaration specifier to even more variables handling vmodes.
- Modified the new GUI text offsets to fit within the main GUI rectangle
- Added timed 'simulation' of triple 'Down' press, to ensure proper screen update
GSModeSelector v0.23s3(2010.01.06) by doctorxyz and dlanor (compiled by doctorxyz)
(NB: This was attached on post #924, only for dlanor and others developers consideration)
- Internal improvements:
- BSOD issue due to caching/timing: _sw and _lw macros changed to entire expression, preceded by 'volatile' keyword (to avoid caching)
- gsKit OSD issue: Special handling of 1080i/720p vmodes, wich demands more VRAM than others
- OSD improvements:
- Idented a little bit for right (this avoid cutting of left characters on HDTV1080i vmodes)
GSModeSelector v0.23t(2010.01.02) by doctorxyz and dlanor
- Added a coloured border for the entire GUI screen
- Corrected code indentation for large parts of the 'main' function (from OSD to PAD stuff)
- Added outline rectangle to the screen edges in OSD section
- Corrected MAGH/MAGV scaling (for GUI only) of various new vmodes
- Removed duplicate vmodes differing only in MAGH (only affected GUI)
- Removed duplicate vmodes differing only slightly in screen centering
- The above eliminated a total of 11 vmodes, leaving 31 in the program
- Corrected description of PS1 modes to show that those HDTV modes are only temporary, and will be changed to PAL or NTSC mode when the PS1 game starts, thus tricking the PS1 driver into enforcing PAL or NTSC mode, by first trying to enforce an HDTV mode. This means that it can be useful to set these modes even with a TV set that can not display HDTV modes, provided you can start the game 'blindly' (exit to uLE and use a shortcut button for "PS2Disc" command).
- Changed NTSC and PAL display offsets (yet again) to be optimized for quality direct-video cables (SCART or Component) rather than the crappy composite cables. (Let the 'flame wars' begin...) Since this is a program intended for people who want improved viewing, optimizing for worst case cables makes no sense...
NB: v0.23t is based on a number of intervening beta versions, not detailed here.
Some of the changes included require that you delete your old GSM.CNF, before saving a new one, as the some of the CNF content has been redefined. The old CNF files will jhave no effect on the new version, but you need to remove them before saving a new CNF.
GSModeSelector v0.23r(2009.12.15)by doctorxyz and dlanor
==>Hey, this the real v0.23r release ;-) <==
v0.23r
- Fixed BSOD/freezing issue reported on some consoles using the v0.23q release (it was caused by non-expected value from strtol(ROMVER_data,NULL,10))
-Added the assembler directives 'noreorder' before and 'reorder' after DisplayHandler routine (whenever I discover potentialy dangerous code, I try to diminishes the chance of bad circumstantial side effects after compiler code rearrangement)
-All predef vmode array has their dw and dh real values (which were taken/guessed from several docs) increased by 1, in order to conform them with previous versions of GSM. And those vmodes 479 rows heighted were changed to 448 rows
- PS2Link now is invoked from the old standard path for mc("mc0:/BWLINUX/PS2LINK.ELF" )
GSModeSelector v0.23q(2009.12.14)by doctorxyz and dlanor
(appears v0.23r on OSD instead of v0.23q, due to my lack of attention. It doesn't work on some consoles)
- Now with 29 vmodes*, among 4 categories: VGA/SDTV/HDTV/PS1
- vmode activation only after [DOWN] button pressing**
- Now the ROM Version is displayed
- Changed exit messages contents, size, color and centralization
- (Re)added the "Rez adaption formulas.txt" file into the docs subfolder***
* Many descriptions were renamed. Some vmodes params were guessed, based on rule-of-three. the syncv parameter value was zeroed (due to a safety caution) whenever its "magical number" value was unknown
**In order to reach all allowed vmodes implemented for each console version without passing a non-supported one(s) that would freeze/crash it (specially if on old console versions)
BTW, only during the GSM initialization, a vmode is activated respecting the following precedence order:
- Force that vmode saved on CNF File Slot 0
- Force VGA vmode if user press [TRIANGLE]
- Force vmode automatically (according to the console region)
***On previous releases, I had deleted it by mistake
GSModeSelector v0.23p(2009.12.06)by doctorxyz and dlanor
(For slim PSTwo users: Do not use this version, since it can be considered faulty, and definitely unsuitable for you)
- Modified menu command handling to prevent single-button commands from blocking recognition of some button combos
- Modified user_mode array command prompt, to include current slot content info showing the base vmode value of the current slot, or that the slot is unused. This is crucial to avoid loading some vmode that is incompatible to the current console. (Which can happen when an MC is moved between consoles of different models.)
- Added status message showing success/failure of CNF save attempts (no more guessing)
GSModeSelector v0.23o (2009.12.05) by doctorxyz and dlanor
- Modified 'Makefile' of 'loader' subprogram for compatibility to latest PS2SDK
- Modified ps2-packer invocation method (using same method as OPNPS2LD uses)
- Removed redundant ps2-packer components from GSM source package
- Removed comment marks that disabled vmodes not working on doctorxyz's PS2
- Removed a duplicate entry from the predef_vmode array (failed commenting)
NB: Due to space limitations changes for many versions are removed.
NB: Pleach check the changes.txt file in the latest release for a more extensive changelist
Note also that some old versions with boot problems have been removed from the downloads.
If you find errors, please report them. Thank you.
Thanks to doctorxyz, dlanor and all those that contributed (and still contribute) for this project.
Documentation for GSM cannot be found yet, since we are in a early beta test stage; But we accept astute readers as canditates for this noble task... ;-)
How to keep youself updated
We suggest you sign up this thread, just clicking and enabling the "Subscribe to this Thread" (from "Thread Tools" menu).
Last edited by dlanor; 06-30-2010 at 08:07 AM.
Reason: Housekeeping 2
GOAL
GSM intends to make on-the-fly conversion from the original graphic mode of PS2 game (or application) choosen by user, to the ones he/she wants to force.
One of benefits of using GSM is have a progressive scan output for a game originally designed to use interlace output. Or have a VGA output in your CRT/LCD Monitor for your preferred games. It seems great, isn't ii?
Well, GSM just makes a simple upscaling. It doesn't making interpolation (i.e. it doesn't add extra pixels / lines). So it doesn't increase the internal(=original=source) resolution, only the output (=forced=target) one.
So, there is no miracle here... The greater the quality of source (original) resolution of the game, the better will be the results that will be displayed on target (forced) resolutions - specially on the higher ones, where the images naturally tend to be pixelized. BTW, see "List of games using your PS2 to the maximum" topic below.
CONVERSION EXAMPLES
Typically from...
PAL 640 x 512 interlaced (even/odd fields or framed) mode (50Hz)
...or...
NTSC 640 x 448 interlaced (even/odd fields or framed) mode (60Hz)
...to:
- HDTV 720x480 progressive mode (60Hz) *
- HDTV 720 x 576 progressive mode (50Hz) *
- HDTV 1280 x 720 progressive mode (60Hz) *
- HDTV 1920 x 1080 interlaced mode (60Hz) *
- VGA(VESA) 640 x 480 (60/72/75/85 Hz) **
- VGA(VESA) 800 x 600 (56/60/72/75/85 Hz) **
- VGA(VESA) 1280 x 1024 (60/75 Hz)**
* Via Component cable
** Via VGA cable (or adaptor connected to Component cable)
REQUIREMENTS
1. ELF Launch method:
a) Modchip with DEV1(DEVolution mode #1) option, that allows ELF booting from mc0 (mc0:/BOOT/BOOT.ELF)
b) uLE (Unofficial Launch Elf) and/or FCMB (Free Memory Card Boot)software, which allows ELF execution from many devices (mc, mass, hdd, cd, dvd, ...)
c) Bootable PS2 CD, you can do it putting the ELF file into a ISO image built by CDGENPS2 (http://www.zophar.net/utilities/ps2dev/cdgenps2.html)
2. TV/Monitor
This requirement here depends on your purposes when using GSM, for instance:
- A ordinary interlaced SD (Standard Definition) TV set, to force PAL or NTSC modes
- A PS (Progressive Scan) SD (Standard Definition) TV set, to force progressive modes
- A CRT/LCD Monitor set with SoG (Sync-on-Green) feature, to force VGA modes
- A LCD/Plasma HD (High Definition) TV set, to force HDTV modes
3. Cable/Connection
This requirement here depends on the previous one, for instance:
A/V Connection between console and TV/Monitor
- Console -> Composite cable -> TV
- Console -> Component cable -> TV
- Console -> Component cable -> Monitor
- Console -> Component cable -> (homemade or manufactured) VGA Adaptor -> Monitor
- Console -> Component cable -> (homemade or manufactured) VGA Adaptor -> TV
- Console -> (homemade or manufactured) VGA cable -> Monitor
- Console -> (homemade or manufactured) VGA cable -> TV
HOW TO USE IT
- Unzip GS Mode Selector "GSM.ELF" from zip file attached here
- Take all measures needed to boot it on your console
- Run it!
- Follow the GSM OSD instructions in order to choice and set your preferred mode using the joypad buttons
- Start PS2 Browser (and consequently title, FCMB or ESR according to your console settings) or HDLoader
- Enjoy!
Please Note!
- GSM can not be auto-launched from FMCB, it will black screen, if you want to auto launch it please configure FMCB to auto boot separate uLE instance, then uLE to auto GSM, then GSM to auto change to saved mode, and boot to PS2 browser.
(Link to files already configured to do this from USB here)
GSM Compatibility List for PS1/PS2 Titles
This is a contribution from DarkCrono666; please help him on this task, filling the form with your test results.
GSM COMPATIBILITY LIST
Whenever needed and possbile, the following two GSM Compatibility lists will be updated by DarkCrono666 with your contributions.
Similar Software
- Blaze VGA and Xploder HDTV Player (from Blaze). The GUI from these programs gives an idea what is possible to do with GS Modes. You can also read the latest Xploder HDTV Player Press to learn about the concepts being explored by GSM (http://gear.ign.com/articles/723/723551p1.html)
- PS2 Zone Loader (from unknown author - Source code shared by Fusion). The PNSelector and yPosHanlder functions has the essential C & MIPS code needed to force an specific GS Mode. You can find CD/DVD/Source Code from PS2 Zone - Loader into SKS Apps site, just browser here (http://sksapps.com/index.php?page=mis.html) for "Zoneloader" ;-)
- ps2force480p (from asmodean - source code share by him). Specific GS HDTV480p Mode and DY field patch for specific ISO and ELF files from games.
Native HD (High Definition) / PS(Progressive Scan) support on some titles
"Generally, progressive scan mode is activated by holding the Triangle and Cross, or "X," buttons down after the PlayStation 2 logo appears."
Source: "List of PlayStation 2 games with HD support" http://en.wikipedia.org/wiki/List_of...ith_HD_support
Some Words (by doctorxyz)
- GSM is just a cool hobby for me (and nothing more than this).
- For all English native speakers, my apologizes in advance since English is a foreign language for me
- For the masters of PSX-Scene: I am not so skilled as I would like to be... Anyway, I am doing my best
- I see myself only as a very limited “sorcerer's apprentice”... Humble is appreciated here
- I have a restricted agenda for this cool project due to obvious personal and professional reasons
- Feel free to help us with your suggestions and comments (here and by PM)
- This project is not only mine, it is OURS!
- At last... What really matters here is conclude this project successfully!
Some of History (by doctorxyz)
The original name of this thread was "Customized HDLoader to boot games on VGA Mode". The doctorxyz original goal was just to play his preferred Playstation 2 game (GT4 - Gran Turismo 4) installed on HDLoader on his LCD Monitor through VGA Cable and with the best vmode (video mode) settings I could obtain from GS (Graphics Synthesizer).
After some work he made a VGA Mode patch for HDLoader's Splash and Main screens. But only for that... Not for games started by it (For them, he was getting only BSOD).
Then he realised that into PS2ZoneLoader app (source code shared by fusion), there were two functions there, called MySetGsCrt(in C Language) and yposHandler (MIPS ASM Language), responsible for PS2ZoneLoader's PNSelector (PAL/NTSC Selector) feature.
Together with this, after release this thread he perceived that other PSX-Sceners needs could take us to a generic patch app for all video modes for all PS2 console versions that work with many cables/connections and SD/HD TVs and LCD/CRT monitors sets as possible.
So turn this idea into reality would a really nice app not only for him, but also for many PSX-Sceners.
Maybe doctorxyz be good on researching and ideas, but not so good on coding (due to time and skill restrictions).
Some months after this thread start, dlanor, an experienced PSX-Scener, join us, sharing his own ideas and opinions; his contributions has been a giant leap to the progress of this thread, in terms of quality and speed, that this thread deserves; this is the reason doctorxyz named dlanor as the project head.
Last edited by doctorxyz; 05-18-2010 at 07:03 AM.
Reason: be and not am
VGA CABLES/ADAPTORS
There are some options to get your VGA cable or adaptor. This naturally depends on your personal choices (buy a pre-made or make it yourself), and your display device type as well (look for technical specs on its user manual, contact manufacturer or make some reasearch on Internet) .
1. For SoG display devices 1.1. Pre-made
Quote:
Originally Posted by urbigbro
Here is the cheapest pre-made way to connect your PS2 component cable to a VGA adapter (~$5 US). The other methods are just for providing multiple outs to hook both a SOG monitor and HDTV without having to swap cables all the time.
If you can be sure that your TV supports sync on green, I recommend a component->VGA adapter, hooked up to the PS2 component cable. They only cost about $3 US at monoprice for a 6 footer. They also have longer and shorter sizes. They ship internationally, but I have no idea the shipping costs.
*None of these cables/switches have a chip to strip the sync signal from the green cable, so they will not work on non-SOG display devices.
This is the cheapest non-homebrew way I know to do this.
Alternatively you could run the PS2 to a VGA splitter box, so you don't have to physically switch cables all the time. Then use the component->VGA adapters on the output of the box to the component in and a regular VGA cable to the VGA input of the TV. $18 plus $3 for another component->VGA cable.
For even more flexibility you could use a VGA matrix box, to let you control each input-output independently. eg. two signals from two sources on two displays. I have used the 4x4 Matrix box in a 3 projector installation and run a computer and DVD in 480i over 100 feet, so I know they work well with interlaced and progressive signals.$28
Some LCDs also accept VGA, or component signals through the DVI connector, thought this is not common in my experience. My HP 2335 LCD does this.
So to summarize, the cheapest non-homemade/homebrew ways to get your PS2 component cable to connect to your VGA SOG display device are specifically:
VGA male to 3x RCA female (harder to find, and only work if your monitor has removable VGA cable, VGA female-female gender changer required if non-removeable)
VGA male to 3x RCA male with 3x RCA female to female coupler/gender changer (easiest to find, still only work if your monitor has removable VGA cable, VGA female-female gender changer required if non-removeable)
Picture of female-female VGA gender changer.
In a perfect world you could buy a VGA female to 3x RCA female to hook straight from your PS2 component cable to VGA cable without gender changers needed, but alas, I have not seen one commercially available.
2. For non-SoG display devices 2.1. Pre-made
(WAITING FOR PSX-SCENERS CONTRIBUTIONS TO PUT A USEFUL AND CONDENSED TEXT HERE) 2.2. Homemade (DIY - Do It Yourself)!
I found an interestant and updated schematics on "Recommendation for a PS2 vga box" thread, from shoryuken forums (http://forums.shoryuken.com/showthread.php?t=159035). 2009.10.20 -> Today I receive from Gilbert thanks Gilb!) an updated and fixed version shared by him. Of course, I uploaded it here, too! ;-) 2009.10.27 -> IN PROGRESS: Improvements by Gilbert and katananja. After I receive their feedback (and ASAP) I will update this 3rd. post. USE THIS-->2010.01.07 -> Improvements by Katananja and Gilbert concluded (see the "PS2 VGA Diagram Rev by GillBert_rev2.pdf" file and latest photos attached here) ;-) Thanks for both!!! 2010.01.11 -> Capacitors' voltage for the "PS2 VGA Diagram Rev by GillBert_rev2.pdf" (by Katananja):
- C1, C2, C3 = 25V
- C5, C10, C11, C12 = 16V 2010.05.18 -> Note about 220 uf caps on non-SoG display devices
Despite of the official PS2 Linux VGA cable has not capacitors on it, there are some circumstances where 220 uf caps are neeed on each RGB signal; the reason is clarified by reading these old Gradius' posts (found by Albino I2hino):
Quote:
Originally Posted by Gradius
if your monitor support 0.7V you don't need the caps at all, it's useless. You can even cut the monitor life because of that, if you don't know.
Quote:
Originally Posted by Gradius
this one is only applicable for 1.0V video level monitors only.
Moderns VGA monitors can do both, 1.0V and 0.7V. If you setup our monitor to 0.7V you'll see the right levels. My old Samsung 753DFX can do both, so I didn't mind with these caps at all.
2010.08.11 -> Thanks Rotosound_rb666 for tolding me (in fact, remembering me :-} about your cool project... Here is for those interested on it! ;-)
2.3. Homemade (DIY - Do It Yourself)! D-SUB VGA Port Case Mod
Quote:
Originally Posted by Rotosound_rb666
I got it fitted on the right hand side, under the "ledge". Added RCA audio jacks, with. I did the "anti-sony-sog" (synch on green) mod with an LM1881 chip, this is basicly now a built in "Blaze"/Xploder adaptor, software driven. It works, and made more sense that making a cable adaptor, since I just tapped to the board where the a/v out port is monted, there was a convienient 5v source there to power the LM1881.
I t works, and only cost a few bucks to make. $5 in parts, roughly.
===>SOME VIDEO ACRONYMS<===
The text which follows is just a simplification from the original one, "Video Displays and the PS3" (http://www.ocmodshop.com/ocmodshop.aspx?a=1118&p=2912). I tried to keep only the things related and useful for GSM project.
SDTV
Stands for "Standard Definition Television" and it refers to legacy TV standards. There were three competing SDTV standards: NTSC (used in most of the Americas and in some places in Asia), SECAM (used in France, Russia, and former colonies of both), and PAL (used just about everywhere else in the world).
NTSC
Stands for "National Television Standard Committee" and is the original television standard. NTSC ran at a resolution of 640x480 interlaced pixels with a refresh rate of 60 Hz. Originally NTSC only supported black and white images, but color support was later retro-fitted into the standard.
PAL
Stands for "Phase Altering Line" and was created after color support was added to the NTSC standard. PAL ran at a resolution of 640x576 interlaced pixels with a refresh rate of 50 Hz, and its main advantage over NTSC was the tint of the picture never needed to be adjusted.
Interlaced Video
In order to conserve bandwidth over a limited-bandwidth connection, an interlaced video scheme sends two images containing a single frame of video to the display, one after the other, with one image containing half of the vertical lines of video, and the second image containing the other half. The display then puts them back together before displaying the full frame. Although this reduces the bandwidth used, the picture is not as good, because sometimes the frames come out of sync, giving the picture noticeable video artifacting. (PS2 owners know the effect as "the jaggies".) The maximum frame rate of interlaced video is 60 frames/second.
Progressive Scan Video
This schemes send a single image containing the frame to the display. It takes twice the bandwidth of interlaced video, but the image is much sharper and does not suffer from any artifacts brought about by interlacing frames. The maximum frame rate of progressive scan video is 30 frames/second.
4:3
This is the standard aspect ratio used by NTSC TV, and is also the standard aspect ratio on non-widescreen computer monitors. (An aspect ratio refers to the number of number of horizontal pixels per vertical pixel.)
16:9
This is the most common widescreen aspect ratio used in HDTV sets. (Most widescreen computer monitors are actually 16:10; see below for details.) Most of the time, when a game or DVD says it supports "widescreen", it really means 16:9 support.
16:10
This is the second most common widescreen aspect ratio. It is very rarely seen on TV sets, but is very common in widescreen computer monitors, mainly because 16:10 resolutions are more backward-compatible with 4:3 aspect content. Many 16:10 displays support letterboxing 16:9 video so it doesn't look stretched.
XXXXi/p
This refers to the resolution of the picture. The XXXX refers to the number of vertical lines in the picture, while "i" stands for interlaced and "p" stands for progressive scan. Typical resolutions are 480i/p, 576i/p, 720i/p, and 1080i/p.
CRT
Stands for "Cathode Ray Tube" and is the original TV display technology. CRT technology is time-tested and cheap, but CRT-based TV sets are big and heavy, susceptible to radio interference, and their image quality tends to degrade over time. CRTs are also susceptible to permanent burn-in, which occurs when an image is displayed on the monitor for long periods of time, causing a "ghost" of that image to be permanently burned into the screen.
LCD
Stands for "Liquid Crystal Display" and is the original alternative to the CRT for displaying images on a screen. LCDs were once expensive, but their prices have dropped dramatically, and their capabilities have increased equally dramatically, since they were introduced in the 1970s. LCDs are digital, and although they are susceptible to burn-in, the burn-in is temporary and will go away shortly after it occurs. The problem with LCDs is they cannot display the color black correctly.
Plasma
This TVs are similar to LCDs, except that they are far better at displaying black and other dark colors, with the main trade-off being that they are more expensive and susceptible to permanent burn-in.
===>VIDEO CABLES<===
The following text is just a simplification from the original one, "Video Displays and the PS3" (http://www.ocmodshop.com/ocmodshop.aspx?a=1118&p=2912). I tried to keep only the things related and useful for GSM project.
Component (Y/Pr/Pb)
Supported Resolutions: 480i/p, 576i/p, 720i/p, 1080i/p
(support varies by display; not all displays support
720i/p or 1080p)
Supported Audio Types: Mono, Stereo, DPL1, DPL2
Picture Quality: Great
Component video is a big step up over S-Video, since it separates the chroma into two separate video color components - luma (Y), the difference between blue and luma (Pb), and the difference between red and luma (Pr) - and provides a big bandwidth boost for one of the sharpest-looking analog video types around. In addition, component video supports multiple resolutions as well as progressive scan video. Its biggest problem is it only synchronizes vertically with the display, so the horizontal aspect ratio of the picture has to be set on the display (unless you don't mind the compressed or stretched picture).
Component (Y/Pb/Pr) video ports are universal on HDTV sets. Also, a handful of computer monitors have component video ports, usually in addition to VGA or DVI ports.
SCART is a European standard for analog video that originated in France, and is rarely spotted outside Europe. A SCART connection can carry either Composite, S-Video, or Component video, so the quality really depends on what the display supports.
IMPORTANT: DVD and Blu-ray playback may not be possible on SCART connections because SCART traditionally defeats the Macrovision encoding of video signals intended to defeat casual piracy.
VGA stands for "Video Graphics Array" and is a slight step up from component video. It is very common on computer monitors, and is present on some HDTV sets as well. Like component video, VGA splits the video signal into separate components. Unlike component video, VGA uses only a single video cable, it supports both vertical and horizontal synchronization (so the user doesn't have to manually adjust the monitor's aspect ratio), and it only supports progressive scan signals.
VGA ports are sometimes identified as "RGB" on some displays.
Sony once made an official VGA cable for the PS2, but it was only bundled with the Linux Kit, it only supported monitors that supported "sync on green" synchronization (the majority of which are, surprise surprise, Sony monitors), and it only really worked with Linux (it unofficially worked with other games that supported progressive scan). Most "VGA boxes" for the PlayStation consoles are nothing more than upscan converters, that take S-Video or some other video type, and convert it to VGA. Blaze Gear was the only company that made a true VGA cable for the PS2 that actually worked.
PLEASE HELP ME TO PUT VGA HOMEBREW CABLES AND ADAPTOR SCHEMATICS AND EXPLANATIONS ON THIS POST (ALREADY PUBLISHED SOME PAGES AHEAD) IN A ORGANISED WAY IN ORDER TO HELP OTHER PSX-SCENERS INTERESTED IN DIY (DO IT YOURSELF). IT WOULD BE GREAT FOR THEM, FIND THE BASIC INFORMATION IN A SINGLE POST! TKS IN ADVANCE
Last edited by doctorxyz; 10-16-2009 at 01:37 AM.
Reason: More images, better explanations
GS Registers being trapped by GSM
They are: SMODE2, DISPLAY1, DISPLAY2 and SYNCV.
We are using:
- SMODE2, DISPLAY1 and DISPLAY2 GS Registers (and inherent bitfields) as the variables to control screen size and scale.
- SYNCV to adjust vertical synchronization.
SMODE2
This register should be updated whenever a new vmode takes place; It is responsible to define how the data from the framebuffer will be read; there are 3 different bitfields into it:
DISPLAYx
DISPLAYx (i.e., DISPLAY1 and DISPLAY2) registers should be updated whenever a new vmode takes place; It is responsible to define screen size and scale; there are 6 different bitfields into each of them:
Code:
.--------.-------.---------------.---------------------------------------.-------.
| Name | Pos. | Format | Contents | Mask |
|--------+-------+---------------+---------------------------------------+-------+
| DX | 11:0 | int 0:12:0 | x pos in display area (VCK units) | 0xFFF |
| DY | 22:12 | int 0:11:0 | y pos in display area (raster units) | 0x7FF |
| MAGH | 26:23 | int 0: 4:0 | magnification in horizontal direction | 0xF |
| MAGV | 28:27 | int 0: 2:0 | magnification in vertical direction | 0x3 |
| DW | 43:32 | int 0:12:0 | display area width - 1 (VCK units) | 0xFFF |
| DH | 54:44 | int 0:11:0 | display area height - 1 (pixel units) | 0x7FF |
'--------^-------^---------------^---------------------------------------^-------^
- DX and DY control the screen positioning offset in physical units (not pixels)
- MAGH and MAGV define the relationship between physical units and pixels
- DW and [B]DH/[B] define the size of the visible screen sections in physical units (not pixels)
- The physical units are the VCK clock for horizontal axis and raster lines for the vertical axis
Diagram displaying the relationship among DISPLAY1/DISPLAY 2 GS Registers fields DX, DY, DW, DH, MAGH and MAGV
Source: DarkCrono666 (art), doctorxyz (inputs)
"Those six values are the component bit fields that together comprise the contents of a DISPLAYx register. Those are two of the main registers we patch to achieve proper scaling and centering of enforced GSM vmodes.
Into GSM, MAGH and MAGV are never directly controlled by the user, but are automatically adjusted for best possible rendering of a 'requested' vmode (requested by game or other software) into the physical vmode enforced by GSM (as specified by the user in the GUI). DW and DH define the width and height of the physical vmode, with the units being HLines for the vertical axis and VCK clock periods for the horizontal axis. This relates to pixels by the following equations:
Width_in_pixels = (DW+1)/(MAGH+1);
Height_in_pixels = (DH+1)/(MAGV+1); DX and DY define the physical offset of the top left screen corner, using similar units as DW and DH.
DX,DY are primarily used for screen centering, but due to the automatic adjustments of GSM the relationship between enforced and requested DW, DH pairs also has a very strong influence on the effective borders, though their influence is always symmetrical around the screen center."
Source: dlanor (http://www.psx-scene.com/forums/show...&postcount=672)
SYNCV
This is an undocumented GS Register that is pached for some vmodes which require it, using "magic numbers"; there are 6 different bitfields into it:
Code:
.--------.-------.---------------.---------------------------------------------------------------------------------------------------.
| Name | Pos. | Format | Contents |
|--------+-------+---------------+---------------------------------------------------------------------------------------------------|
| VFP | 9:0 | int 0:10:0 | Vertical Front Porchinterval |
| VFPE | 19:10 | int 0:10:0 | Vertical Front Porchinterval E????(The last word meaning is a mystery - at least, for me) |
| VBP | 31:20 | int 0:12:0 | Vertical Back Porchinterval |
| VBPE | 41:32 | int 0:12:0 | Vertical Back Porchinterval E????(The last word meaning is a mystery - at least, for me) |
| VDP | 52:42 | int 0:11:0 | Vertical Differential Phase |
| VS | ??:53 | int 0:??:0 | Vertical Synchronization???(Someone please confirm that "S" means Synchronization) |
'--------^-------^---------------^---------------------------------------------------------------------------------------------------'
"Vertical synchronization (v-sync, v-synch, vbl-sync, vbl-synch) refers generally to the synchronization of frame changes with the vertical blanking interval. Since CRTs were nearly the only common video display technology prior to the widespread adoption of LCDs, the frame buffers in computer graphics hardware are designed to match the CRT characteristic of drawing images from the top down a line at a time by replacing the data of the previous frame in the buffer with that of the next frame in a similar fashion. If the frame buffer is updated with a new image while the image is being transmitted to the display, the frame buffer gives it the current mishmash of both frames, producing a page tearing artifact partway down the image.
Vertical synchronization eliminates this by timing frame buffer fills to coincide with the vertical blanking interval, thus ensuring that only whole frames are seen on-screen.
Sophisticated software such as computer games and CAD packages often allow vertical synchronization as an option, because it delays the image update until the vertical blanking interval. This produces a small penalty in performance, which can be enough to reduce a program's frame rate below the refresh rate of the monitor on computationally strained systems.
VSYNC is also the name of the signal indicating this frame change in analog RGB component video."
Source: "Vertical synchronization" (http://en.wikipedia.org/wiki/Vertical_sync)
I hadn't further details about it, but after reading...
"each of the vertical scanning periods is defined by a vertical synchronization signal SYNCV having a constant cycle. Each of the vertical scanning periods is comprised of a pulse width interval of the verticalsynchronization signal SYNCV, a back porch interval BPV, a vertical active interval ACTV, and a front porch interval FPV. In the vertical active interval ACTV of these, an image is actually displayed vertically on the screen, while the back porchinterval BPV and the front porch interval FPV are displayed as black borders at top and bottom ends respectively on the screen."
Source: "US Patent 7224350 - Video display apparatus and video display method" (http://www.patentstorm.us/patents/7224350/fulltext.html)
... I was able to add some brief bitfields explaination on "Contents" column.
Remaining undocumented registers to be documented: (SMODE1, SYNCH1, SYNCH2)
I believe that after reading and understating the documentantion on links above (on SYNCV section), some people among us (especially - but not only - electronic-engineering skilled) could guess the meaning for these remaining undocummented GS Registers... Please contribute!!! ;-)
About Resolution Adaption Formulas
"Each time GSM force a resolution change it will activate and analyze the requested values of the:
- DISPLAY1/DISPLAY2 six bitfields (DX, DY, MAGH, MAGV, DW, DH)
- SMODE2 two bitfields (INT and FFMD)
So as to calculate the resolution in pixels that the forced program will 'believe' it is using.
Then the patch program will use that information, combined with the stored values of DX, DY, DW, DH chosen by the user in the setup menu, in order to calculate values for all six of the bitfields that will allow optimized rendition in the chosen physical video mode.
That's the total purpose of the equations in 'Rez adaption formulas.txt', whose real implementation lie in the inline asm sections of 'Adapt_X.c' and 'Adapt_Y.c'."
Source: dlanor (http://www.psx-scene.com/forums/show...&postcount=185)
Last edited by doctorxyz; 12-09-2009 at 11:47 PM.
Reason: Fixed link to one of posts from dlanor
NB: I do not think that those master codes starting with "F" can work with CodeBreaker as used with HDLoader. For such usage you always need the master codes starting with "9".
Best regards: dlanor
I wasn't trying it on HDLoader, I was using the original disc and I couldn't get it to switch the video mode at all from PAL to NTSC. I know this method works because I have a confirmed working code for fight night round 3, I get a blue screen when using anything other value than 00, 01, 02, 03 on my SDTV one of the values results in a image being displayed with a rolling screen it may have been 480p since forcing 480p on the gamecube using SD-Boot has the same effect.
doctorxyz do you notice a difference in resolution and screen position when using 02 and 03? which Mastercode did you use to get the BSOD?
doctorxyz do you notice a difference in resolution and screen position when using 02 and 03? which Mastercode did you use to get the BSOD?
Hi,
Unhappily, I tested only 0x1A (VGA640x480@60Hz) mode on my LCD monitor (not TV) and got BSOD. After that, I tried to implement more patching (related to DISPLAY1/2 registers) but without sucess, since BSOD still appears.
But I will try test mastercode on TV ASAP, after installing CB for HDL and connect PS2 on TV ok.
UPDATE ON 29.07.2009 -> I tested with CB for HDL but nothing changes at GT4 :-( ... But maybe I entered uncorrectly the codes... So I think must understand before how to convert and type mastercodes. So that is time to learn it ;-)
Please check new update from my previous post and the following information (I am not using mastercodes yet, I am editing the ISO itself).
Unhappily, I am not using my PS2 on TV, but on my Philips 160VW LCD monitor (1024x768 native resolution).
I have a Matrix Infinity modchip that has VGA mode option, but it is too limited.
When trying to activate VGA mode for GT4, I disable VGA option from modchip and use a uLE modded version (that boots on VGA mode) to boot HDL modded version (that boot Splash and Main screen on VGA mode) and finally try to boot my GT4 modded version on VGA mode... ;-)
BR,
Ah I see a bit easier to do tests without a cheat device.
Various conflicting guides on making making mastercodes there doesn't seem to be any definitive method that will work with any game thrown at it though :-( I mainly rely on the scesifsendcmd jal method since it pretty much works for everything apart from the odd game here and there just like when scePadPortOpen / read doesn't work.
PS2DIS - Disassembler for PS2 ->
To easily find function labels from ELF files
IDA Pro - Interactive DisAssembler -> To interactively find hex or strings patterns
(without wildcard - i.e. joker char - support), label code and data sections and put
comments on them
XVI32 - Hex Editor -> Support for script files (XSC) in order to automate patch process.
Also permits directly change opcodes (or string sequences) from ELF files and find hex
or strings patterns on them (with wildcard - i.e. joker char - support).
Crimson Editor - Unix Text Editor for WIN32 -> To edit Source Code Files and use it with
your Toolchain
@kevstah2004
Wow man! Tons of precious info... Thanks!
I intend use some of these info to make a generic patch to any video mode with all options we can get from GS, and working with HDLoader.
Maybe someone reading these posts could help to make my code work. This the reason I am posting a lot of information here. Because I must confess maybe I have no enough skill to conclude this project alone.
-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
UPDATE on 30.07.2009 - I read them all. I also found an interesting tool called "Omniconvert" and useful CB (my cheat device) information from its help...
But where can I find more information about syntax of CB commands?
Last edited by doctorxyz; 08-01-2009 at 11:40 AM.
Reason: More info
All the info / guides are on http://www.codemasters-project.net/p...ortal/news.php just click the bar on the left hand side, I recommend registering at forums too http://www.codemasters-project.net/vb/
as well as http://www.thegshi.org/ and ps2dev.net
I can't code so don't ask, i'm just a point and shoot hacker much like how Bung started out, I should really get my arse into gear and start learning to code properly for the ps2 but it looks too daunting and tool chains are a bitch to setup.
Location: The beach with great weather year round.
Posts: 894
Thanks for doing a thread here in English so more people can read and help out with this!
VGA is the only other thing I could hope for my homebrew, gaming use.
Everything else is either already been done or being worked on to some degree
In a perfect scenario this work could lead to a VGA implementation in FMCB, and/or uLE making a TV and or VGA box no longer needed for any PS2 stuff I do
So, I think one of (many) possibilities to our "Customized HDLoader to boot games on VGA Mode" project is discover how that patch was done, and apply a similar one to Blaze VGA tool, since forum colleagues stated that it works with HDLoader for lucky people that have their PS2 Laser lens stilll working...
Remembering that I am not using this solution yet because my laser lens was gone, and I would like to improve this app to manipulate better GS configurations (MAGH, MAGV, DW, DH, etc). Or even make one from scratch.
If this method works, why not does further analysis in order customize Blaze to get specific values for each game?
So coders... Go further with these folowing information! ;-)
After:
- Disasming CB93 and CB93HDL with PS2DIS
- Comparing both files using FC (File Comparte) tool from Command Prompt
- Copy some hex opcodes from XVI32 hex editor and pasting them into Crimsom Editor
- Analysing all these stuff
I conclude that:
1. There are patches on CB ELF File Header Info. See comparision (starting at 0x00000000, using FC and XVI32). Please note that I also attached here screenshots from PS2 Elf modder v 1.3 tool (made by cYs Driver):
-> UPDATE ON 05/08/2009(dd/nm/yyyy) -> ffgriever told that he just added another elf section for all his patch data.
2. UPDATE ON 05/08/2009(dd/nm/yyyy) -> ffgriever clarified that there are patches to the CB unpacker/decrypter routines(where CB executable is compressed and encrypted), not to the CB core. See comparison (using PS2DIS):
First patch
Code:
CB93 -> jal $01005f70 # 01000598:0c4017dc v FNC_01005f70
CB93HDL -> jal $01005f78 # 01000598:0c4017de v FNC_01005f78
-> UPDATE ON 05/08/2009(dd/nm/yyyy) -> ffgriever stated that this first patch leads to the changed part (the first two opcodes of the old function are "jr $ra" and "nop", just in case) code.
CB seeks for a disc in drive. Then it reads the key and uses it to unpack/decrypt the contents. This changed function just writes some data into memory at a special point, which simulates that the disc has been detected and the proper key has been read. That's all.
Actually, there are also some other changes in the checking routine.
Second patch
Code:
CB93 -> lui at, $0010 # 01000780:3c010010 at=$00100000
jalr at # 01000784:0020f809 at=$00100000
nop # 01000788:00000000
CB93HDL -> lui at, $0010 # 01000780:3c010010 at=$00100000
j $01005fa8 # 01000784:084017ea v __01005fa8
nop # 01000788:00000000
-> UPDATE ON 05/08/2009(dd/nm/yyyy) -> ffgriever said that It is a place, where the CB is unpackerd/decrypted (if the key was right, and thanks to previous patch it always will be ). In this place it just jumps and starts execution of the real executable. It's a perfect location to do all the patching (disabling disc seek, spin down, executing my launcher instead of parsing system.cnf). After the patching is done, it just jumps to the entry point of the real CB).
This way I didn't have to actually unpack the CB. It unpacks/decrypts itself. I just supply the correct key and disable some "features", then patch it once it is ready to be patched.
3. From 0x01005F70 and so on, we have the patch code itself. Specifically, at 0x01005F70 and 0x01005FA8 we have two routines made by ffgriever that makes the magic, i.e., loads any ELF file in the following paths, instead of launching CD/DVD:
Code:
hdd0:/__boot/CB_launch.elf
mass:/BOOT/CB_launch.elf
mc0:/BOOT/CB_launch.elf
hdd0:/__boot/boot.elf
mass:/BOOT/BOOT.ELF
mc0:/BOOT/BOOT.ELF
mc0:/B?DATA-SYSTEM/BOOT.ELF
mc1:/BOOT/BOOT.ELF
mc1:/B?DATA-SYSTEM/BOOT.ELF
"?" means region code.
Use ps2-unpacker tool to unpack Blaze VGA, looking for the place using PS2DIS, and make the same. See more ffgriever tips to get this goal (shared to us by rotosound_rb666):
rotosound_rb666 -> "I want to patch the blaze vga elf the same way to patched codebreaker to launch something other than the cd.
I've unpacked it and hex edited it, and found a couple of occurances of 'cdrom0:\SYSTEM.CNF;0'.
Any ideas on what I should replace that with, or rather, how to correctly phrase that to redirect the boot instruction to something else?
I have the offending elf unpacked, if you want it, but I think I can pull this off myself, with minimal help from you, who obviously have some experience I lack."
ffgriever -> "Replacing the string won't give you anything.
The application would normally read and parse it to gain the name of the executable to launch.
There are few ways, but most common are:
1. Find the parser function/code and make the output to be the executable you want to launch.
It has a drawback though... if the app didn't load the modules necessary to access device,
you won't be able to access it (so in most cases only cdrom and mc... and sometimes there will be only cdrom available)
2. Embed your own launcher into the executable and hijack the process that would normally lead to parsing system.cnf
and launching the executable. This way your launcher will be executed (and there you can do anything you want)...
Just make sure your launcher is small enough and will not get overwritten (it's wise to place it somewhere under 1MB).
Then create multisection elf to make it simple and voila."
Last edited by doctorxyz; 08-05-2009 at 09:49 AM.
Reason: Text fixes, after clarifications from ffgriever
Despite of topic be written in Portuguese, do not worry about that... Just download files attached on first post.
One of two zip attached files also has the source fragment used to make VGA mode on uLE possible (just compare ".before" extension files with correct extension files - these last are the modded ones).
Maybe dlanor or other uLE project maintainers could implement it on future releases of uLE ;-)... But I really do not know if they are interested on this stuff.
__________________
"Work is 1% inspiration plus 99% transpiration"(Albert Einstein) SCPH-90006 HK(BIOS 2.30)Thunder Pro II Gold
Logitech Cordless Wireless Action
LG Time Machine LCD TV 32" 32LB9RTA component
Philips LCD Monitor 160VW9FB/78 VGA
VGA homemade adaptor / Hyperkin VGA-2000 Box
FiiO E5 Headphone Amp
Last edited by doctorxyz; 08-04-2009 at 08:29 PM.
Reason: Clarifying information
After:
- Disasming CB93 and CB93HDL with PS2DIS
- Comparing both files using FC (File Comparte) tool from Command Prompt
- Copy some hex opcodes from XVI32 hex editor and pasting them into Crimsom Editor
- Analysing all these stuff
I conclude that:
Wouldn't it be easier to just ask, rather than disassembling and comparing all of this?
Quote:
1. There are patches on CB ELF File Header Info. See comparision (starting at 0x00000000, using FC and XVI32). Please note that I also attached here screenshots from PS2 Elf modder v 1.3 tool (made by cYs Driver):
Simple. I just added another elf section for all my data. This way it mad this patch as simple as possible.
Quote:
2. There are 2 patches on CB core (where games are started). See comparison (using PS2DIS):
Nope. This is not a patch on the core. The codebreaker executable is compressed and encrypted. What you found here is the patches applied to the unpacker/decrypter.
Quote:
[First core patch
Code:
CB93 -> jal $01005f70 # 01000598:0c4017dc v FNC_01005f70
CB93HDL -> jal $01005f78 # 01000598:0c4017de v FNC_01005f78
Nope. This one leads to the changed part (the first two opcodes of the old function are "jr $ra" and "nop", just in case) code.
Codeabreaker seeks for a disc in drive. Then it reads the key and uses it to unpack/decrypt the contents. This changed function just writes some data into memory at a special point, which simulates that the disc has been detected and the proper key has been read. That's all.
Actually, there are also some other changes in the checking routine.
Quote:
Second core patch
Code:
CB93 -> lui at, $0010 # 01000780:3c010010 at=$00100000
jalr at # 01000784:0020f809 at=$00100000
nop # 01000788:00000000
CB93HDL -> lui at, $0010 # 01000780:3c010010 at=$00100000
j $01005fa8 # 01000784:084017ea v __01005fa8
nop # 01000788:00000000
It's a place, where the codebreaker is unpackerd/decrypted (if the key was right, and thanks to previous patch it always will be ). In this place it just jumps and starts execution of the real executable. It's a perfect location to do all the patching (disabling disc seek, spin down, executing my launcher instead of parsing system.cnf). After the patching is done, it just jumps to the entry point of the real codebreaker)
This way I didn't have to actually unpack the codebreaker. It unpacks/decrypts itself. I just supply the correct key and disable some "features", then patch it once it is ready to be patched. Hijacking is fun .
Wouldn't it be easier to just ask, rather than disassembling and comparing all of this?
Master,
First of all, thank you very much to add great value to this thread with your comments!
I have just corrected my previous post (#15).
In fact, I already asked (other things) you by PM... I wait some time, but I dunno because I had no response. Now it is clear for me that something bad happened to my PM message. And this the reason I stopped boring you with my newbie's stupid questions.
Would you mind to give the best addresses to make a similar solution to Blaze VGA to call HDL from mc0/hdd/mass instead of call anything from cd/dvd?
Make the same to Xploder HDTV Player would be great too, but it seems more difficult since it is not work with HDLoader (maybe Xploder HDTV Player uses the same addresses that HDLoader does to stay its cores resident).
__________________
"Work is 1% inspiration plus 99% transpiration"(Albert Einstein) SCPH-90006 HK(BIOS 2.30)Thunder Pro II Gold
Logitech Cordless Wireless Action
LG Time Machine LCD TV 32" 32LB9RTA component
Philips LCD Monitor 160VW9FB/78 VGA
VGA homemade adaptor / Hyperkin VGA-2000 Box
FiiO E5 Headphone Amp
Last edited by doctorxyz; 08-05-2009 at 09:57 AM.
Reason: POST #15 CORRECTED & text completeness
Master PM some hints... So as a limited sorcerer's apprentice I am studying them (respecting my time and skill limits)... Well, patience is everything!
I opened PS2ZoneLoader's "bootmaster.elf" on PS2DIS and discovered n useful labels.
So I picked up opcodes from some labeled functions and looked similar for hex sequences into HDLoader ELF file.
I was surprised that MIPS assembly source code from both (PS2ZoneLoader and HDLoader) are identical in some functions - for instance, "memcpy" and "findSyscallTable". Note that using these HDLoader's functions could make my code smaller.
I intend to mod "installPNSelector", "installDebugExceptionHandler", "myGsSetCrt" functions from PS2ZoneLoader, and inject them some address on HDLoader ELF.
But I still do not know where is the best place.
Maybe I need to sacrifice some HDLoader GUI message data area to put those. Or maybe not. It depends on the result of my research.
Suggestions are welcome!
__________________
"Work is 1% inspiration plus 99% transpiration"(Albert Einstein) SCPH-90006 HK(BIOS 2.30)Thunder Pro II Gold
Logitech Cordless Wireless Action
LG Time Machine LCD TV 32" 32LB9RTA component
Philips LCD Monitor 160VW9FB/78 VGA
VGA homemade adaptor / Hyperkin VGA-2000 Box
FiiO E5 Headphone Amp
Last edited by doctorxyz; 08-08-2009 at 10:42 AM.
Reason: English language corrections, more info
I was surprised that MIPS assembly source code from both (PS2ZoneLoader and HDLoader) are identical in some functions - for instance, "memcpy" and "findSyscallTable".
There's really nothing surprising about it.
Though HDLoader eventually became a commercial project, it started out as any other homebrew project, and I assume that Sjeep used the standard ps2dev.org libs throughout, except for those sections he had to code entirely himself, as being unique to HDL needs.
Standard functions like those you mentioned here will be fully identical for all homebrews using the same generation of ps2dev libs, except for minor deviations in compile-time register assignments (also affected by optimization settings).
@all
Work in progress... I embeed PS2ZoneLoader core into a byte array and I trying to make my testing ELF install and activate it, letting user decide to force NTSC/PAL/VGA modes before launch uLE from mc. If this test succeed, I go further to launch HDL from mc (of course, without destroying my force GS Mode routine).
@jepjepjep
Quote:
Originally Posted by jepjepjep
I just thought I would post to cheer you on.
Thanks for your encouragement words.
@dlanor
Quote:
Originally Posted by dlanor
Though HDLoader eventually became a commercial project, it started out as any other homebrew project, and I assume that Sjeep used the standard ps2dev.org libs throughout, except for those sections he had to code entirely himself, as being unique to HDL needs.
I found this on Net
"(...) About 5% of the HDLoader code is made up of open source code from ps2dev.org including ps2lib, libhdd, ps2drv etc
(all of which I have had a part in the development of anyway) (...)"
Source: "Hdloader - The Real Story"(by malloc) -> http://www.maxconsole.net/?mode=news&newsid=3249
__________________
"Work is 1% inspiration plus 99% transpiration"(Albert Einstein) SCPH-90006 HK(BIOS 2.30)Thunder Pro II Gold
Logitech Cordless Wireless Action
LG Time Machine LCD TV 32" 32LB9RTA component
Philips LCD Monitor 160VW9FB/78 VGA
VGA homemade adaptor / Hyperkin VGA-2000 Box
FiiO E5 Headphone Amp
Last edited by doctorxyz; 08-12-2009 at 10:58 AM.
Reason: More info
Linear Mode
