Gs Mode Selector Tutorial

RE: Global Defense Force, -48 is totally fine, nothing is cut off at top or bottom at all!As for Runabout, I find -48 is the best for it too. This cuts off some of the bottom, but all you lose is total time + score. You can still see your speed and most importantly the top of the screen you can see your time remaining and the map fully.SO, as for BCV:This is complex to explain so I'm not actually going to do a full tutorial, but I.DID. manage to get it to work properly! It requires a LOT of faffing about though and a spare memory card.Basically, what you have to do is find a way to install 'FreeMcBoot' on the memory card (as I have a chipped PS2, I copied the files of Free McBoot to a USB, then burned a uLaunchELF ISO which would allow me to access the install files on the USB from the PS2, ran the disc, found the usb, ran the FreeMcBoot ELF).
The Global Descriptor Table (GDT) is a data structure used by Intel x86-family processors. Loading a selector into a segment register automatically reads the GDT or the. Ds, ss, es, fs, and gs should point to this descriptor dw 0xffff; segment limit first. The GDT is still present in 64-bit mode; a GDT must be defined, but is. GS Mode Selector, confused on how to use it. I've fiddled around in the menu, changed the settings, but I can't figure out how to start a game with forced higher resolution. Then, you can go into the browser from the OSD menu, insert your disc, and select it when the system reads it. This is assuming you're trying to boot an original disc.
There is a 'noobie pack' which has all the FreeMcBoot stuff you need if you google.With FreeMcBoot your PS2 will launch into a new browser direct from the memory card(!) I have no idea how it does it, but it works. You now (or you can do this at the same time) need to install a thing called 'Graphics Synthesiser Mode Selector' (usually just called GS Mode I think) on the memory card too. This is a thing you run which allows you to select any video mode for games!To run BCV now., what I do is make sure the FreeMcBoot memory card is in, then put my original BCV disc in the machine (tray open). The machine boots into FreeMcBoot, I launch uLaunchELF from that, then launch GS Mode from that, select NTSC and my y+x fix requirements, close the disc and exit GS Mode into the browser.The game loads and is fixed to my needs!.I actually have it set up with some configuration files (also found on the web) which means I just put BCV in the drive, and when I turn the PS2 on I hold L1 and it boots right into GS Mode selector.
I.still. need to select NTSC and y+x fixes every time, but it's a lot faster.Using this method you can run ANY PAL PS2 games on an NTSC machine from the original discs with a bit of fiddling each time you run it, but it's a one-stop solution.Final note:I think GS Mode selector actually naurally y-fixes for PAL on NTSC, so I don't have to set it. However for whatever reason I am required to x-fix BCV and Snowboard Racers 2 to -48 to center it on screen. Weird I know.Oh and if you don't already have a chipped PS2, you need to use some other method to get FreeMcBoot on your memory card, but it's possible with a variety of methods, really whatever you use to boot your PAL games as it is. Aerisdead wrote: Global Defense Force -48 is totally fine, nothing is cut off at top or bottom at all!As for Runabout, I find -48 is the best for it too.
This cuts off some of the bottom, but all you lose is total time + score. You can still see your speed and most importantly the top of the screen you can see your time remaining and the map fully.SO, as for BCV: What I do is make sure the FreeMcBoot memory card is in, then put my original BCV disc in the machine (tray open). The machine boots into FreeMcBoot, I launch uLaunchELF from that, then launch GS Mode from that, select NTSC and my y+x fix requirements, close the disc and exit GS Mode into the browser.The game loads and is fixed to my needs! Using this method you can run ANY PAL PS2 games on an NTSC machine from the original discs with a bit of fiddling each time you run it, but it's a one-stop solution.Thanks for the update, I left the 48 Y Fixes you posted earlier in the OP.For Battle Construction Vehicles, I use PS2 Swap Magic along with a Flip Top, which gives similar results as GS Mode program, although it has no adjustment for the Y Fix. The GS Mode looks better and also has an option to run HDLoader which can run an installed BSV game. I'm not sure if the PAL game will be converted to NTSC since HDLoader is run after GS Mode prompts are set. Can you give this a try and see if BCV runs NTSC after installed to the Hard Drive?If it works, this would give BCV hard drive convenience, but after loading all the programs to get to the game with the NTSC conversion.
I would still like to find a way to convert BCV to avoid the extra loads, I'll post if I find a way to crack that compressed Elf file.@ Claw - A good idea on the duel mode PAL/NTSC TV option, but it would mean another screen taking up shelf space for just a few additional games. For me not feasible since I am happy with my NTSC only WEGA HD CRT. Aerisdead wrote:I don't have a hard drive, so I can't test that. I'm using a slim.
I could try and run it off a USB stick but honestly the USB is only 1.1 so I don't trust it would run well, seems like a waste of time.Even an external 2.0 USB hard drive would be slower then internal on a Fat PS2. Something to look at if you have a lot of PS2 games, the hard drive has so much faster loads and also menu driven convenient.Can you try the install of BCV on the USB Memory Stick and try out GS Mode? A curiosity if the PAL to NTSC conversion does work for installed games, notably this compressed Elf.
I updated the OP with a first time use of a different PS2 PAL to NTSC conversion tool.PS2 PAL to NTSC Lemmings ADR Patcher no Y FixI had difficulties getting this game converted to NTSC with the Y Fix program. ADR Patcher worked but does not compensate for screen position. Fortunately the game itself allows for manually adjusting the screen position.This game has a long history dating back to earlier PCs and the Amiga computer.
I really wanted to play this game again thru the PS2 on the big screen. It even has EyeToy levels if one wants to try a different approach. The game works best with a Mouse, weird that there is no USB Mouse option. No problem, a allows use of a Mouse or Trakball!
I love playing all the Levels again, not huddled to a computer screen, but now on a HD CRT!PS2 PAL to NTSC Silent Hill 2 - 56 Y PositionI confirmed that there is no 60hz mode available from the settings screen of the game. An easy Y Fix conversion which has already been posted by another member. I saw no need to convert mine since I already have the US Greatest Hits version which is identical to the PAL release with the extra levels.PS2 PAL to NTSC Silent Hill Making Of DVD - DVD DecryptorAt first I extracted the files with DVD Decryptor to the hard drive, I then used Media Coder to convert the PAL VOB files to NTSC MPEG files. The MPEGs all played fine thru Windows Media Player, but how to get the Disc menu to work properly again? There are also multiple chapters that would have to be set correctly again.My plan was to burn a new DVD with PVR Plus along with the original IFO and BUP files to get a proper Menu and Track matched disc. This really proved to be a nightmare to work so I went a more direct route figuring the PAL video would stay as such.I again used out DVD Decryptor, this time just creating an ISO.
I knew it would get rid of the Region Code, but not convert the PAL to NTSC video itself. I then burned a copy from the Decrpyted ISO and surprised that it worked! A full dedicated PAL conversion, the screen displays properly in NTSC! It is strange the original disc is Region encoded 2 even though the video on the disc supports both PAL and NTSC formats.The PAL Silent Hill is worth getting just to get this bonus Making Of DVD. It has an Art Gallery, Biographies of the key people involved, a really great insider video of the Japanese developers talking about the game.
It is British narrated which confirms the footage was made for the PAL package, the Japan developers in the documentary speak in their native Japanese with English subtitles.There are also Trailors and Game Show footage of various games by Konami. One of the Konami trailors is the Microsoft game PS2 Age Of Empires 2 which does not have a US release. Maybe a trade for Microsoft obtaining Konami's Metal Gear Solid on the PC? Also a couple of hidden boxes in the Menu, which include a French Spoof of Silent Hill Blair Witch style and Castlevania Chronicles Director's Interview.The Silent Hill DVD disc includes a sub folder called DVD@ccess.
The program is by Apple and allows an 'iTunes' style of search to web links for DVD Movies. Looks like an interesting tool but did not bother with this. I hate the slow down affect experienced before on iTunes when it searches online for Album Covers. Attachments PAL Lemmings - PAL Silent Hill 2 - Art Of Silent Hill.jpg (210.93 KiB) Viewed 4149 times. Hi,I want to play Final Fantasy X International (NTSC/J) on my PAL PS2 and I am using Swap Magic.
It works well except for one thing. The screen is shifted up 48 pixels. So I tried to use ps2ntsc2palyfix but without success. The conversion to PAL is working because I have big black borders on top and bottom of the screen. But the Y fix is not working. This is bad because I don't need PAL conversion only the Y fix.
I also tried ps2pal2ntscyfix and then the Y fix is working but in the wrong direction of course.I found a modified version of ps2pal2ntscyfix on the web which is doing only a Y fix and no conversion. Maybe sombody is interested in this:. This modified version is not suitable for me because the Y fix is again in the wrong direction (it shifts the screen up).Maybe I should try the Graphic Synthesizer Mode Selector now or has somebody a good idea of what to do?Thanks,dccoder84. Dccoder84 wrote:I found a modified version of ps2pal2ntscyfix on the web which is doing only a Y fix and no conversion. Maybe sombody is interested in this:This modified version is not suitable for me because the Y fix is again in the wrong direction (it shifts the screen up).I want to play Final Fantasy X International (NTSC/J) on my PAL PS2.Maybe I should try the Graphic Synthesizer Mode Selector now or has somebody a good idea of what to do? I tested now the GS Selector Mode. The picture is almost perfect now only some little borders at the top and the bottom.Are these small borders unavoidable?
Or can they be fixed too?Thanks for the link to the non conversion Y Fix program.PAL - 625 line resolution, and a refresh rate of 50 HzNTSC - 525 line resolution and refresh rate of 60HzNTSC is shorter image compared to the the PAL screen, I think you are stuck with those borders. I can't remember, does the game itself have a 'stretch setting' in its own setup menu? Very nice job on the NTSC to PAL conversion going the Graphic Syntesizer route. Can you post what GSM setting is used to get the picture centered with just tiny borders? I'll post the information back in the OP.
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.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.Here you can get GSM public releases (by doctorxyz and dlanor).STATUS:Beta testing stage.Releases:GSModeSelector by doctorxyz.Chanelog. I somehow read it wrong and those expressions were correct. In fact, it seemed like I no longer got those graphical glitches, even without changing those lines.I guess it is related to the change in parameters to the 480P and 576P modes, since the previous commit had that changed.I've done some more fixes, related to the sync instruction:.
GSM: changed all sync after mtc0 to sync.p as it has to be sync.p. Changed all lq to ld for the branch evaluations, as only the low 64-bits are supposed to be considered. Removed unnecessary sync.l & sync.p instructions. GSM: Changed preservation and restoration of context to better match the original Level 2 exception handler and preserve LO+HI registers.
Optimized GSM engine.When I wrote 'unnecessary', I mean those that I see no need for. Whereby the EE instruction manual doesn't indicate a need for those.The description for the mtc0 instruction states that a sync.p (not just sync) is required to ensure that the write to the cop0 register completes.GSM will now use only k1 (and its backup location at address -0x20 via kseg3) to preserve the context.
It will also preserve LO+HI register pairs (lo, lo1, hi, hi1), which get changed by multiplication and division operations.@ once wrote that there is some risk involved in doing this, but I would like to try to make the code more efficient.For optimizations, the beqzl instructions were replaced with normal beqz instructionsto maximize use of branch slot. Nops were reduced to reduce code size, but interlocks will still occur.The EE mult MMI is used, so that we can save on some instructions.Since the removal and/or changes to the placement of sync and sync.p might cause game compatibility to change, I would appreciate it if somebody can let me know if any game suddenly became incompatible.Test. Click to expand.Some games might use a frame buffer size like 512x448. That is one of the allowed sizes for NTSC.The DW for NTSC and PAL are both 2560.2560 / 640 = 4x, while 2560 / 512 = 5x.
These are all nicely supported.While DTV 480P's DW is likely 1440, given that the documented horizontal resolution is 720 and libgraph multiplies the width by 2.1440/640 = 2.25x. 1440 - 2x640 = 160px. Not perfect, but the border will be quite small (11%).1440/512 = 2.8125x. 1440 - 2x512 = 416px.
28% of the screen will go into borders.What happens is that it'll round down the magnification factor to the nearest integer and center the video. That's why you get large borders.You can try the other video modes, but none of them will be perfect for such a case. I don't think we can fix this perfectly, since the problem is that the game wasn't designed for other video modes.
From feedback, I have made the FIELD emulation setting an option. It is disabled by default.I think not emulating the flipping for those games that use the half-pixel offset trick is the more correct thing to do, given that they were using a low-resolution buffer and GSM is already doubling the height of such frame buffers - hence why the video is pixelized. As of now, I don't have a way to deinterlace the video anyway.I have also removed the last sync.l instruction before the eret instruction. I wasn't sure if it was a good idea to remove it, but because the kernel doesn't have such a thing. It might not be necessary.So if there are any new incompatible games compared to yesterday's build, please let me know.Today's build.
Some games might use a frame buffer size like 512x448. That is one of the allowed sizes for NTSC.The DW for NTSC and PAL are both 2560.2560 / 640 = 4x, while 2560 / 512 = 5x. These are all nicely supported.While DTV 480P's DW is likely 1440, given that the documented horizontal resolution is 720 and libgraph multiplies the width by 2.1440/640 = 2.25x. 1440 - 2x640 = 160px. Not perfect, but the border will be quite small (11%).1440/512 = 2.8125x.
1440 - 2x512 = 416px. 28% of the screen will go into borders.What happens is that it'll round down the magnification factor to the nearest integer and center the video. That's why you get large borders.You can try the other video modes, but none of them will be perfect for such a case.
I don't think we can fix this perfectly, since the problem is that the game wasn't designed for other video modes. From feedback, I have made the FIELD emulation setting an option. It is disabled by default.I think not emulating the flipping for those games that use the half-pixel offset trick is the more correct thing to do, given that they were using a low-resolution buffer and GSM is already doubling the height of such frame buffers - hence why the video is pixelized. As of now, I don't have a way to deinterlace the video anyway.I have also removed the last sync.l instruction before the eret instruction. I wasn't sure if it was a good idea to remove it, but because the kernel doesn't have such a thing. It might not be necessary.So if there are any new incompatible games compared to yesterday's build, please let me know.Today's build.
Click to expand.When you have a low-resolution (as seen under 480P) game that flickers when the FIELD emulation option on, it probably uses the half-pixel offset trick. The benefit of that trick, was that you get to have double-buffering with memory savings.
But it does not work when a progressive video mode is used.So for at least now, we have to choose between upscaling its true frame buffer resolution or living with two sets of scan lines that do not merge.Personally, I think it may be best to use the original video mode for these games.The only time when I think it is a cause for concern, is when the game looks worse now than when older GSM versions are used. Click to expand.Hold on. Are you using 480P mode by GSM on this game, but with the game using its usual NTSC/PAL?I thought you meant to say that it looks squished when you select 480P within GSM and used the progressive option in the game. Now to think about it, that doesn't make sense. I must be tired.GOW II uses 512x512 for PAL, which isn't a factor of the 480P/576P screen width (Frame buffer width does not divide DW). The remainder is so huge that 28% of the screen goes into those borders.I guess it might use some other resolution for 480P mode.
The resolution can be changed during runtime and this may be one of those games. Are you using 480P mode by GSM on this game, but with the game using its usual NTSC/PAL?I thought you meant to say that it looks squished when you select 480P within GSM and used the progressive option in the game. Now to think about it, that doesn't make sense. I must be tired.GOW II uses 512x512 for PAL, which isn't a factor of the 480P/576P screen width (Frame buffer width does not divide DW).
The remainder is so huge that 28% of the screen goes into those borders.I guess it might use some other resolution for 480P mode. The resolution can be changed during runtime and this may be one of those games. Click to expand.Thank you. Uk truck simulator 2 download full version. So it seems like I was wrong about it and only the SCPH-75000 and later do support 576P.The PSX is likely an exception to this rule: it supports this mode, despite having a lower ROM version number than the ROM from the SCPH-50000a, SCPH-50000b and SCPH-70000.The PSX also shares the same GS revision as the SCPH-75000, which is also shared with some SCPH-70000 consoles. So I cannot think of a better way to identify what console supports this mode.
Other than going with the current homebrew idea of 'v2.20 and later'.But for our case, I made it v2.10 and later because there is a PSX with v2.10. It is likely harmless to use the GSM code for setting up 576P mode for the PSX with v1.80.New functions for initializing the DVE properly for 576P mode, have been added on behalf of the EE kernel. It was based on code from Kernelloader.
Regarding SetGsCrt: PS2Linux also reimplemented SetGsCrt in its own way.For newer consoles that have ROMGSCRT (v1.60 and later), the functions within ROMGSCRT are used instead. ROMGSCRT implements SetGsCrt (yes, it is a duplicate) and GetGsDxDyOffset.But for older consoles, it would do things on its own and we can see how it works.There are a two parts to it:1. The part that writes to the.2. The part that. This is only required for VESA and the DTV video modes.
DVE functions can be.You might already know this, but because the hardware was changed at the SCPH-75000, its equivalent for dvepreparebus doesn't support the old hardware registers anymore (moved to 0xBF8019xx). This might be the reason why Mega Man remarked that this function cannot be used for 'newer consoles', although he didn't clarify what models they were.The 'dev9typedetected' variable is not set in the CEX kernel and is hence likely always 0x00. In the EE kernels, this variable is checked against 0x40, 0x60 and 0x61, rather than whether it is non-zero (in SBIOS).In TOOLs, this is the value known as 'BoardInf', taken with a load byte operation from 0xBF803204. CEX consoles don't even have BOARDINF and also lack any code that deal with it (even within the EE kernel), so I don't know if it is even safe to try to access that register directly.The 'sbcallsetdve' function is a unified function here, but it is split up in the EE kernel; there is one for DTV modes (480P, 1080I and 720P), and other similar functions for the other VESA and DTV video modes (including those for the DVD player).The 576P (0x53) mode was added with ROM v1.80, for the PSX. The PSX seems to have the same GS revision as the SCPH-75000, even though it was about a year older.The v1.90 ROM for the SCPH-50000a and SCPH-50000b do not support this mode, as with the SCPH-70000 (v2.00).The PSX's ROM seems to support all 3 possible DVE interfaces, including whether the DECKARD method is used or not.
This depends on whether the highest bit of 0xbf801450 is not set (checks whether the word value is = 0).EDIT: The writes to the DVE after setdve are possibly required.Within the setdve function call, 576P mode requires the same settings as 480P. For the code after the call to setdve, the commands are similar, except that 576P mode has 1 extra write. Today's build:. Fixed support for J-type instructions. Bits 31:28 were not computed, resulting in failures when the EE jumps from within KSEG.
Removed call to DisableGSBreakpoint from within HookSetGsCrt, so that GSM can change SetGsCrt. It's already being done anyway, during LoadExecPS2, but before SetGsCrt is hooked. 576P now again works on older consoles. 576P will now use the user's GCONT setting (RGB/Y Pb/Cb Pr/Cr).I did tests with my SCPH-15000. I spent quite a few hours working on GSM, thinking that it was a hardware bug because I couldn't even get 480P mode to work there (but it's working on my SCPH-39006 and SCPH-77006).It turned out to be a bug in GSM's code that handled the J-type instructions.At the last minute though, I made more changes (the middle point) and I do not have the TV for my use. So I do hope it works.I do think it will do.
Click to expand.No, haha. I was really tired and I started skipping words. Plus my own explanations sometimes become hard to understand because of that. If you need help to understand anything, please feel free to ask me to clarify myself.
This will also make the information here easier to understand, for other developers who might want to continue the development of GSM. Or if doctorxyz ever decides to return.Basically, the PS2's graphics subsystem is more than just the GS chip.The SSBUS I/F controller (CXD9566R, CXD9611x, CXD9686x, CXD2955R) is actually also responsible for letting the EE talk to the video encoder (DVE) via a I2C bus, which is also used for enabling the copy-protection (Macrovision). It also determines the input clock for later models, which allows the G-chassis (SCPH-37000) and later to support both NTSC and PAL properly.I wrote 'DVE' here, but that is probably not what it really is in all PS2s. I lack the technical knowledge here to know what it should be called, but I know it was a Texas Instruments device that was replaced at some point with the Sony CXM4000R.So while GSM had add-on code for enabling 576P on older consoles that did not support it, it lacked the code for telling the DVE that 576P mode is used.
Hence it might not have been totally 576P mode until yesterday. It also had the GCONT (RGB/Y Pb/Cb Pr/Br) setting hardcoded, but now it will use the user's setting.
Click to expand.If such a signal standard exists, it can be done. Unfortunately, only those who deal with TV signals might be able to create such a video mode properly.When I helped to create the 1080P mode, it was just a copy of the 1080I mode, but with interlace disabled and with the PLL frequency increased.

So it was not really a new video mode.Other than figuring out the pixel clock rate and some settings under SMODE1:The SYNC. registers should be updated as well, since the signal probably has different characteristics from the normal 60Hz signals. The DVE might need to have other settings applied too. Click to expand.It was working, somewhat. It was missing code for setting up DVE and the GCONT setting was hardcoded.I somehow broke that part recently, but I didn't actually figure out what I broke because it started working again after some rebasing.But in the process of that, I found an actual bug in GSM: J-type instructions did not have the upper bits computed, resulting in failures if the EE did a jump from within KSEG.Previously, it was not an issue because GSM was not allowed to monitor accesses in kernel mode, but that also meant that a lot of its extended functionality (i.e. For processing undocumented registers) was also not working.
That part wasn't important for most people though. I was really tired and I started skipping words. Plus my own explanations sometimes become hard to understand because of that. If you need help to understand anything, please feel free to ask me to clarify myself.
This will also make the information here easier to understand, for other developers who might want to continue the development of GSM. Or if doctorxyz ever decides to return.Basically, the PS2's graphics subsystem is more than just the GS chip.The SSBUS I/F controller (CXD9566R, CXD9611x, CXD9686x, CXD2955R) is actually also responsible for letting the EE talk to the video encoder (DVE) via a I2C bus, which is also used for enabling the copy-protection (Macrovision). It also determines the input clock for later models, which allows the G-chassis (SCPH-37000) and later to support both NTSC and PAL properly.I wrote 'DVE' here, but that is probably not what it really is in all PS2s. I lack the technical knowledge here to know what it should be called, but I know it was a Texas Instruments device that was replaced at some point with the Sony CXM4000R.So while GSM had add-on code for enabling 576P on older consoles that did not support it, it lacked the code for telling the DVE that 576P mode is used. Hence it might not have been totally 576P mode until yesterday. It also had the GCONT (RGB/Y Pb/Cb Pr/Br) setting hardcoded, but now it will use the user's setting.
- суббота 25 апреля
- 80