Switchres: modeline generator engine

[bitbytebit]

He actually complained about using Ubuntu but I adviced him to do so as it had been discussed here that 10.10 had the new stuff we needed. I don't really know what he was using for his previous distribution. So this makes sense as he claimed to be changing stuff from xorg when doing tests as he was seeing errors and stuff.

Yeah it seems like Ubuntu would be great, but digging into it more it just looks like they don't want you to customize it or at least don't very well support it (and instead actually seem like the Ubuntu alterations/patches work against it). 

I always thought Gentoo was the easiest to build a distribution from, because you just untar two main archives to a partition, compile/install a kernel, setup a few of the system files, run a few commands to install the packages you want.  Now to get a distribution out of that, once you've setup a base image and then need some easier features for administration of the system, it might get trickier.  If it was setup though to be for one purpose, like running emulators and having a custom installed X Windows and patched linux kernel, xorg.conf for ATI Radeon cards and basic networking and such.  That might be possible, it just wouldn't work great as a generalized desktop system for everybody to use if they weren't specialized for something like our needs.  For a desktop system, you would have to develop the whole administration interface to change the system around for all the different desktop apps and other setups people might want.  Since we are focused on the arcade monitor and having full control of it, using mostly Radeon cards or other ATI cards, I think Gentoo would be able to do that and be put onto a CD/DVD and easily install systems from.

[Calamity]

So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it. And yes, we just wanted a preconfigured system specific for cabs, it would be nice to have a live cd that was even able to read roms from the hard drive's roms directory at a given path, so you could just burn one cd and start your cab with it, to see the difference and how this modelines really work.

[bitbytebit]

So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it.

Sounds good, the README_Gentoo file and GA.sh script from the older SwitchRes archives of the Perl version have all the information to mostly setup the base system, and what I did basically, at this point the kernel needs to be built and a few system files setup, the genkernel package in gentoo is really easy to use for this using 'genkernel --menuconfig all' does it all for you, except entering the grub.conf entry for it. The GA.sh script does the SDL/mame installation and of course the modular GIT archive for Xorg is done before that to build the base X Windows system.  The major difference of course from those instructions would be to use /usr/ instead of /GA/, I just did that for putting it all on a current system with X already installed to have it separate.  Downloading the 2 Gentoo base .tgz file and portage will give a basic partition the needed files for a skeleton system needing the packages I list installed with emerge/portage, and then can get the GIT package for Xorg modular and following the way to use the build.sh file from there install X, and then use GA.sh to download and install SDL/mame (which you can of course redo mame installation again after that to more tweaking.  Of course there's a few extra things I probably left out, main thing is that running emerge --search "package" to find things, emerge -av "package" to install, look under /usr/portage/ for packages, to build all the emulators may need dependencies.  Also a key is installing portage packages may try and install extra Xorg stuff because it depends on it.  I'd say let it, then redo the Xorg GIT install with modular and then run the command possibly to reinstall/compile the packages that depended on X and installed them (or there might be a command even with emerge to not download extra stuff like depencies of X since we have our own install).  Might even be a way to setup portage overrides to force X to use the newest versions, could be ones already there that have to be 'unmasked'.  The Gentoo website basic howto really tells simple step by step instructions which Ves could use if he needed.  Basically with Gentoo it would really be a fully custom compiled Linux system, but all taken care of the details by portage/emerge.  So in the end, this would make a really nice system.  Getting to know Gentoo, if he doesn't, would probably be a very good thing because sounds like it'd really be the best route for all this.  As long as it's centered at just arcade emulation, running mame or other emulators, no desktop expectations, it should be pretty easy and basic.  I'd recommend a lightweight window manager like fvwm, I use that and can provide any help with a basic config file and window desktop that allows things to work right, wahcade is really nice and I have had very good luck getting it to have all the emulators setup in it.  I definitely can give any help needed on setting up the system, have built Linux distributions, was years ago, Gentoo is closest I've ever seen to the steps to custom build one like I originally did completely from sources part by part, but automates it all for you pretty much besides the main steps you go through to partition/setup a fresh install.  It might be lower level on how it's installed to the users diskdrive, I don't know what level Ves has his distributions install at.  It'd definitely be great though  do it this way in the end, plus a Gentoo system in theory with this setup would be very easy to maintain updating it forever, there aren't blocks where you have to reinstall to upgrade ever.  I have a system I've ran for 3 years and can keep it up to date still with the most current Gentoo packages, with Ubuntu it'll make you reinstall each jump so the distribution would have to be refactored from each of those jumps every few months to a year or how often they release.  There's also some advanced ways to have overlays I guess, basically you can take Gentoo, make your own portage system in a sense so it would know about the newer Xorg we use and a mame install with our patches, the kernel with our patches, all built into the main packaging system for it.

[bitbytebit]

So by now I think we should try to replicate what you have there, start with Gentoo and eventually when we have it running with no issues then try to get a distribution out of it. And yes, we just wanted a preconfigured system specific for cabs, it would be nice to have a live cd that was even able to read roms from the hard drive's roms directory at a given path, so you could just burn one cd and start your cab with it, to see the difference and how this modelines really work.

I'm doing an experiment using this page http://en.gentoo-wiki.com/wiki/Build_Your_Own_LiveCD_or_LiveDVD as a reference and also the 'x11' overlay http://www.gossamer-threads.com/lists/gentoo/dev/188190 which basically makes the x11 used the newest one from GIT.  It looks to me like this will essentially build a duplicate of what I have, and also can build a liveCD distribution which is a start and that much closer to a local installed system (basically could be either one, just take out the livecd specifics).

More info on overlays: http://www.gentoo.org/proj/en/overlays/userguide.xml

So hopefully this will help Ves, and I'm hopefully going to get a liveCD that may just be able to run I hope, I'm building a script and system files setup to be able to show how to do it and recreate it too.

Here's a basic script, not fully tested because I'm at the stage where it downloads all the packages and recompiles everything (will take all night or longer)...

Code: [Select]


#!/bin/sh

if [ $1 = "32" ] ; then
        export DO32BIT="linux32"
fi

# If you have not already installed these tools
emerge -av squashfs-tools cdrtools
export LIVECD=/GentooArcade
mkdir -p ${LIVECD}/source

cd ${LIVECD}/source
if [ $1 = "32" ] ; then
        tar -xvjpf ${LIVECD}/stage3-i686-20101116.tar
else
        tar -xvjpf ${LIVECD}/stage3-amd64-20101021.tar.bz2
fi

tar xvjf ${LIVECD}/portage-latest.tar.bz2 -C usr

cd ${LIVECD}/source
mkdir -p proc dev sys
mount --bind /proc proc
mount --bind /dev dev
mount --bind /sys sys

cp -L /etc/resolv.conf ${LIVECD}/source/etc/
#mkdir -p ${LIVECD}/source/etc/portage/
#echo "dev-lang/perl -minimal" >>${LIVECD}/source/etc/portage/package.use
cp -f ${LIVECD}/fstab ${LIVECD}/source/etc/
cp -f ${LIVECD}/make.conf ${LIVECD}/source/etc/
if [ $1 = "32" ] ; then
        echo "CHOST=\"i686-pc-linux-gnu\"" >> ${LIVECD}/source/etc/make.conf
else
        echo "CHOST=\"x86_64-pc-linux-gnu\"" >> ${LIVECD}/source/etc/make.conf
fi
cp -f ${LIVECD}/net ${LIVECD}/source/etc/conf.d/

${DO32BIT} chroot . /bin/bash --login

#
# now we are in the chrooted environment
#
env-update && source /etc/profile
echo "Set password for the root user:"
passwd # set the root password for the new environment in case of problems later

# Basic system information
export HOSTNAME="arcade"
export DOMAIN="groovy.org"
export TIMEZONE="America/Chicago"

cp /usr/share/zoneinfo/${TIMEZONE} /etc/localtime
cd /etc
echo "127.0.0.1 ${HOSTNAME}.${DOMAIN} ${HOSTNAME} localhost" > hosts
sed -i -e 's/HOSTNAME.*/HOSTNAME="${HOSTNAME}"/' conf.d/hostname
hostname ${HOSTNAME}
hostname -f

# Localization
echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
locale-gen

# Get x11 Overlay
emerge --sync
emerge -av vim git autounmask layman
layman -L
layman -a x11
echo "source /var/lib/layman/make.conf" >> /etc/make.conf
# Unmask x11 overlay
ls /var/lib/layman/x11/*/*/*.ebuild| sed -e s/\.ebuild//g|sed -e     s/\\/var\\/lib\\/layman\\/x11\\///g|awk -F "/" '{ printf("autounmask %s/%s\n", $1,$3) }' |tr '\n' '\n' >/root/unmask_x11.sh
sh /root/unmask_x11.sh
rm -f /root/unmask_x11.sh

emerge -v -e system
emerge -v -e world
emerge -v xorg-server x11 mesa libdrm libsdl \
        memtest86+ localepurge genkernel gentoolkit dmraid \
        livecd-tools emerge scripts mingetty grub \
        chardet numpy pygobject setuptools fvwm \
        radeon-ucode vixie-cron talloc zlib dhcpcd openssh \
        alsa-utils alsa-headers alsa-firmware mercurial \
        subversion libxml2 nasm rar syslog-ng \
        mercurial zip vim unzip vim \
        libpthread-stubs intltool automake automake-wrapper \
        libxslt gperf freetype fontconfig makedepend talloc \
        libpng xkbcomp pygame pygtk gconf

#
# Exit CHROOT
#
exit
# Now outside the chroot, put the environment back
cd ${LIVECD}/source
umount sys proc dev usr/portage/distfiles
env-update
source /etc/profile

mkdir -p ${LIVECD}/target/files/source
rsync --delete-after --archive --hard-links --quiet \
        ${LIVECD}/source/boot ${LIVECD}/target/

cp -a ${LIVECD}/source/isolinux ${LIVECD}/target

rsync --delete-after --archive --hard-links \
        ${LIVECD}/source/ ${LIVECD}/target/files/source


#
# Build Live CD
#

cd ${LIVECD}/target/files
rm -f ${LIVECD}/target/livecd.squashfs
mksquashfs source/ ${LIVECD}/target/livecd.squashfs

touch ${LIVECD}/target/livecd

cd ${LIVECD}
mkisofs -R -b boot/grub/stage2_eltorito \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
        -iso-level 4 -hide-rr-moved -c boot.catalog \
        -o ${LIVECD}/livecd.iso -x files ${LIVECD}/target/
#
# Making changes to live CD
cd ${LIVECD}/source
mount -o bind /proc proc
mount -o bind /sys sys
mount -o bind /dev dev
mount -o bind /usr/portage/distfiles usr/portage/distfiles
chroot . /bin/bash --login
#Chroot to 32 bit environnment if you plan to use the livecd on different arch
linux32 chroot . /bin/bash --login
env-update
source /etc/profile
# LIVECD UPDATE STARTS HERE
# MAKE HERE THE DESIRED UPDATES, for example :
emerge --sync
emerge world
freshclam
# LIVECD UPDATE ENDS HERE
exit
umount sys proc dev usr/portage/distfiles
env-update
source /etc/profile
#




Of course you can't run this script itself, must be split up to the chroot part because after that point it won't run the code since the script is outside the chroot (thinking of making 2 scripts and the middle is in the chroot section, that'd probably do it).  Also I'm to the part where I'm doing the emerge of all the packages, so I haven't tested past that point.  Yet this again should show Ves essentially the basics I think of getting a Gentoo build/install with the newest Xorg setup which would support things properly.  Also I haven't added in the kernel setup/patching/build part yet which goes in there around the exit of the chroot, plus need to setup grub in there, that page link explains it all.

Also if you see the part where I autounmask a list of packages for the x11 overlay, that is a trick that bypasses the issues in the second link I put above.  By default you can't install them, they are masked, but that'll undo it and it seems to be now installing them. 

[Calamity]

Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.

[bitbytebit]

Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.

Update on this, I've finally gotten a pretty nice LiveCD using Gentoo and almost exactly my working setup, linux kernel patch, and auto creation of xorg.conf with the changes necessary to it.  I'm right now improving the console menu, but also here's an interesting Perl script that will create a xorg.conf dynamically when given either cga or d9800 or multi as the command line option.  "create_xorg.pl d9800 > xorg.conf".  If ran on the Linux console, it'll use Xorg and edit the output with the correct h/v ranges and proper default modes and debugging output options.  Should have the scripts and files to create the build for the live CD and an iso for 32 bit pretty soon, for a good basic framework/example and possibly nice bare bones mame/emulator system in Linux utilizing all the newest DRM Kernel Mode Switching and vsync openGL stuff, boot up with a frame buffer console on arcade monitors.

Code: [Select]


#!/usr/bin/perl

$monitor = "cga";

if ($ARGV[0] ne '') {
        $monitor = $ARGV[0];
}
print "# $monitor Monitor configuration\n\n";

my $hfreq_range = "";
my $vfreq_range = "";

if ($monitor eq 'cga') {
        $hfreq_range = "15.250-16.500";
        $vfreq_range = "50-60";
} elsif($monitor eq 'd9800') {
        $hfreq_range = "15.1-38";
        $vfreq_range = "40-85";
}

`Xorg -configure 2>&1 >/dev/null`;

my @newfile = `cat xorg.conf.new`;
my $in_monitor = 0;
my $in_device = 0;
foreach(@newfile) {
        my $line = $_;
        chomp ($line);
        if ($line =~ /^Section \"Monitor\"/) {
                $in_monitor = 1;
        } elsif ($line =~ /^Section \"Device\"/) {
                $in_device = 1;
        } elsif ($line =~ /^EndSection/) {
                if ($in_monitor) {
                        if ($hfreq_range && $vfreq_range) {
                                print "\tHorizSync $hfreq_range\n";
                                print "\tVertRefresh $vfreq_range\n";
                                print "\tOption \"DefaultModes\" \"False\"\n";
                                print "\tUseModes \"ArcadeModes\"\n";
                        }
                        $in_monitor = 0;
                } elsif ($in_device) {
                        print "\tOption \"ModeDebug\" \"True\"\n";
                        $in_device = 0;
                }
        }
        print "$line\n";
}

if ($hfreq_range && $vfreq_range) {
        @mode = `switchres 640 480 60.00 --monitor $monitor`;
        foreach (@mode) {
                chomp($_);
                $_ =~ s/\s+/ /g;
                $_ =~ s/^\s//g;
        }

        print "\nSection \"Modes\"\n";
        print "\tIdentifier \"ArcadeModes\"\n";
        print "\t$mode[1]\n";
        print "\t$mode[2]\n";
        print "EndSection\n\n";
}



Basically I've got a build script for creating the system in a directory, runs a separate script in the chroot of that directory to fully setup the system.  There's a few files I have that are copied there, then after that I have a script that can copy that base directory of the system and tailor it into an iso image which currently is only 250 meg and contains mame/mess/zsnes/nestopia/stella/mupen64plus emulators and fully working X Windows from GIT and 2.6.37-rc3 patched kernel with should work on every system possible (from basic Ubuntu .config file), and wahcade right now ready to be setup.  Right now I am looking at the ways to have a drive to use as the ROM directory and other to use for the home directory for the arcade user on it, so they can save stateful information and actually have ROMs to use (have the freely distributable ones on there by default to test). 

So it's sort of a proof of concept to show the most current Linux stuff and switchres working together, but also not looking too bad either as more than that eventually with some more intelligence in how it sets up the writable drives/network and finishing rough edges that may exist.  I figured this xorg.conf creator was pretty useful since it automatically adds the missing parts to allow the X Windows default modes not to happen and can add the correct ranges in needed for arcade monitors.

It'll hopefully give a good template at least, I have done quite a bit extra stuff than on that site to really make this work, but have preserved it all into scripts so hopefully it's now correct and easy to reproduce.  Also I suspect it's not too much of an issue to turn the build into a hard drive install, and I am going to try building the 64 bit version which mostly should just work unless I have bugs in running it for a 64 bit mode build.

[bitbytebit]

Hi bitbytebit, thanks a lot for all that info and material, it will definitely help us.

Experimental 32 bit and 64 bit liveCD using Gentoo and my kernel patch and switchres to demonstrate it quickly without any difficult work building a system and patching etc...

http://arcade.groovy.org/

I'm curious about how this works, issues with it or improvements that could be done.  Simple choice of boot up frame buffer types (640x480/800x600/1024x768 in 15-16Khz and SVGA modes), basic console menu to setup a possible mount of /data/ containing roms, possible /home/arcade/ user mount to preserve changes each boot, network setup if desired.  It's pretty raw and basic, but in testing works quite well and most importantly recreates the results I've had with vsync and resolution/mode flexibility and console boot up on an arcade monitor.

[Calamity]

Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.

[bitbytebit]

Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

It should work with the H9100/d9200/9800/CGA/SVGA types, I actually changed how I did that.  Basically now on bootup you have a boot menu which is going to have to be in the bios mode output so an Arcade Monitor user won't see that.  That's ok because it defaults to the choice for 15.650 Khz mode, only SVGA or D9800 users would find use to change up to 800x600 or just normal SVGA mode.  Then when the kernel bootup happens it kicks into DRM mode and then you'll see the rest of the bootup.  I don't think we'll ever fix it so we can see the grub boot prompt, just like we can't in Windows either.  Grub does have a video mode thing in it but it's only able to use VESA bios modes or something.  I don't know if it can really be more flexible, or changed to be 15Khz too, I am looking at that some but I don't know if it's really necessary though.

Once booted it'll just have a console with a few questions and one is asking your monitor type, so then it'll use that script or another to create a basic xorg.conf with a 648x480 modeline for the desktop.  Then you can start X Windows from that menu, and go from there (right now probably easiest to open an xterm/terminal with a right click and choosing 'new' from the right mouse menu, and using switchres on the command line for games, which it has all the legally distributable ones from the main site on /data/roms/ by default unless you tell it a drive with them.).  It's definitely a bit rough on the way the menu and stuff works, unless you have the /data directory filled with your roms and then run wahcade setup and have it rescan to run switchres for you.  There's lots of room for improvement there, so any issues you have or suggestions on ways it's confusing would be great.

I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.

Wow, that sounds really great.  So what part of the modeline can we modify, is it just the back porch front porch sync pulse stuff, dotclock or just active lines?  Sounds interesting, great that it turns out it's simpler to reload it and excited to get that working.  The couple parts I didn't fully look at is the format that Windows stores the details of the modelines, looked like it's a bit different I'm guessing, or at least stored oddly from what I can tell.  I'll have to start looking at that again, was interested in the read/write part of the modeline details.  Now that I think about it, I think I understand what your saying and the part I've read so far with the basic active h/v lines are not changable after bootup, yet the part I haven't dived into reading with the details (and can alter the refresh rate) is the changeable part and changes the refresh rate of course since that one in Windows is just a label in a sense.  So I am guessing what I currently do with looking at those hxw combos is the first step, then once the best fit is found we'd go in and alter the rest to fit our needed vertical refresh or get as close as possible (just using our current modeline calculations with that hxw), then call that EnumDisplaySettingsAPI call.  Also would need to go in and add custom resolutions with some preset amount we come up with that should generally fit about every game but not always be without some padding.  That sounds very cool, and I'm guessing I should some what be able to experiment with that some even with unpatched drivers for now, just limited in modelines for 60 of them right now. 

[Calamity]

Ok, I see what you mean with the livecd setup, perfect. However, this is something I've always wondered when talking with VeS also: is there a direct way to just read C:\Roms\Mame from our Windows partition and use it with Linux?

The part we must keep for each mode is the active resolution width x height and the refresh label. So for convenience we could preset all modes to 60 Hz, and then tweak them before invoking Mame. So we would be using i.e. 320x240@60 label whatever vfreq we have. We have also the possibility of leaving vfreq label undefined when creating the mode in DALNonStandardModes, so the system would have an unique modeline choice for each resolution, however I haven't tested this yet so I believe it's more secure to stick with the 60 Hz label instead.

There's something interesting I've seen with this version: I can't use my xres increment trick for resolutions with similar vfreq I've been using previously. For some reason this Catalyst is overriding the mode label with the xres, yres values directly from the modeline definition, but it's not enough with using i.e. 321 there, as then surprisingly 320 and 321 defined modes will collapse into the same mode, ruining the results. It would be a big problem if we wanted to use an static mode list as I've been doing, but doesn't matter as we are going to change vfreq on the fly.

There's something else: the precalculated dotclocks values I've been using also seem to be correct with this combination of X300 + Catalyst 9.3. I still have to test them with HD4350 to draw conclusions.

[bitbytebit]

Ok, I see what you mean with the livecd setup, perfect. However, this is something I've always wondered when talking with VeS also: is there a direct way to just read C:\Roms\Mame from our Windows partition and use it with Linux?

Yes, it'll read NTFS partitions in Linux and should be able to do that, although the whole logic of where the ROMS are located will need to be setup of course different than what I currently have hard coded.  If a partition is mounted though as the user directory, like a USB stick/drive possibly, then that would be able to keep the setup of course and that could be one way a person could choose right now and have a pretty nice stateful setup.  You can't write to an NTFS partition from Linux, and I don't have it mount the ROMS partition writable anyways for safety, it only mounts the point if chosen for the arcade user home directory as writable.  There's a basic set of config files for that user in the /home/arcade/ directory, bunch of . dot files mainly, which are pretty useful and should be copied to any writable extra partition/drive used.  Also there's the creation/formatting of the partition which isn't done automatically since right now it's assumed there's already a setup partition for the home directory.  That process of partitioning/formatting is pretty easy on the command line but of course best to use a script to walk through it, and definitely starts to get into some possible danger there if not carefully done. 

I think I have a 64 bit build now, have to test, and also will show me if my whole setup scripts to create the whole thing from scratch are really working right.  I've got that all grouped into a set of scripts to basically run and build the complete development environment, so pretty much all documented on how to create the entire thing in a small bundle of files.

The part we must keep for each mode is the active resolution width x height and the refresh label. So for convenience we could preset all modes to 60 Hz, and then tweak them before invoking Mame. So we would be using i.e. 320x240@60 label whatever vfreq we have. We have also the possibility of leaving vfreq label undefined when creating the mode in DALNonStandardModes, so the system would have an unique modeline choice for each resolution, however I haven't tested this yet so I believe it's more secure to stick with the 60 Hz label instead.

There's something interesting I've seen with this version: I can't use my xres increment trick for resolutions with similar vfreq I've been using previously. For some reason this Catalyst is overriding the mode label with the xres, yres values directly from the modeline definition, but it's not enough with using i.e. 321 there, as then surprisingly 320 and 321 defined modes will collapse into the same mode, ruining the results. It would be a big problem if we wanted to use an static mode list as I've been doing, but doesn't matter as we are going to change vfreq on the fly.

There's something else: the precalculated dotclocks values I've been using also seem to be correct with this combination of X300 + Catalyst 9.3. I still have to test them with HD4350 to draw conclusions.

Interesting, I'm guessing they are aligning everything to 8 then or something, but rounding down possibly?  Also seems like they are are now listening to the actual setting for active lines instead of the label when choosing resolutions, which is how Linux does it through the SDL layer. 

[dmarcum99]

Hi Guys!

This is good news!!  I can't wait to try out the 64-bit Gentoo Live CD that you're talking about.  I am having good success with switchres as well.  Very impressive!!

I have a question for Calamity...sorry I don't mean to hijack.    Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!

[bitbytebit]

Hi Guys!

This is good news!!  I can't wait to try out the 64-bit Gentoo Live CD that you're talking about.  I am having good success with switchres as well.  Very impressive!!

I have a question for Calamity...sorry I don't mean to hijack.    Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!

The 64bit system build is looking good, should be up in a day or less, need to investigate how to get my gens build working since it doesn't do 64bit.  I'm surprised that gens seems like the  only issue right now, thought there'd be more issues between the 32 vs. 64 bit build with my scripts but luckily not.  Of course another thing I need to do for both .iso images is figure out the right configuration to make all the emulators besides mame/mess/mupen64plus/stella (which all behave nicely) actually not try to call the GUI interface and load the ROM as smooth as mame does from wahcade or other frontends.  I had all that working in the past, each one (nestopia/zsnes) has a slight different config file tweak to kick them into gear, plus gens is weird and likes to just load 640x480 with a tiny picture else it's off center which is another issue I've not fully figured out.

Yeah my X850 ATI card sounds like that too besides the fact mines the crossfire edition with no special cable that you can't get for less than 100 dollars to allow 2 video outputs, the noise alone makes me not use that card right now in anything.

[Calamity]

Bitbytebit: the megaupload link you posted seems temporaly disabled...

[bitbytebit]

Bitbytebit: the megaupload link you posted seems temporaly disabled...

Strange, I'll look at getting something better like a dropbox account possibly.  I'm wondering if it'll show back up in a bit, megaupload is odd I guess, I can't even really see in my account that I uploaded the file but the link worked at least a few minutes after I posted it.

[Calamity]

Strange, I'll look at getting something better like a dropbox account possibly.  I'm wondering if it'll show back up in a bit, megaupload is odd I guess, I can't even really see in my account that I uploaded the file but the link worked at least a few minutes after I posted it.

Yes, that happened to me too when uploading drivers there, it might be back by itself later.

I have a question for Calamity...sorry I don't mean to hijack.    Calamity, I have been playing with your hacked 9250drivers and arcade_osd.exe program.  With this program, I can go in and tweak my modeline without having to reboot into dos and play with advv.  I am taking it slow since my time is limited, but for those games where my original modelines were off-centered or over-scanned, this really helped out.  I really want to make use of my 64-bit processor and my radeon 9200SE, but there are no XP 64-bit drivers for this video card.  Is this something you can cook up or is there a good reason why there isn't a 64-bit driver avail?  If I want to go 64-bit, right now I have to use my X850XT and the fan makes it sound like I have a carpet cleaner in my cab!

I'm glad to hear that Arcade_OSD has been useful for you. Unfortunately I haven't done any testing with 64-bit XP or its drivers. From time to time, ATI drops support for its older cards and places them in a legacy driver structure, as far as I know, this has happened twice:

- Catalyst 6.5 -> rebuilt as legacy 6.11
- Catalyst 9.3 -> rebuilt as legacy 10.2

The Radeon 9200 family was dropped since Catalyst 6.6 (first of the above branching) so from there on there are not new drivers available for them, I suppose that includes 64-bit support, so the only possibility would be to force the newer drivers to accept older cards, something that is definitely possible by properly editing driver ini & inf files, though I have not ever tested, and would probably produce blue screens.

[bitbytebit]

Ah I now realize I could have just used Sourceforge since they'll support large files over 1Gig so these should be fine at 255 and 355 meg (32bit and 64bit).  I'll get them uploaded there, both should be ready, just have to run a quick test on them first.  I fixed an issue with proper setup of the arcade user home directory so this will be better anyways than the one at megaupload.

[bitbytebit]

I have 32bit and 64bit version ISO's uploaded, and a git repository containing the scripts that build the distribution/LiveCD ISO.  The scripts mostly download everything needed extra, the Gentoo base files, you'll just need to manually download the right Linux kernel (README file explains more).  Total a build directory takes about 5-6 gig of space per architecture, and takes about a day to completely build, might be a few bugs still but seemed to mostly work smooth when I built the 64bit version.  So Ves may want to look at the git repository for this on the sourceforge site...

arcade.groovy.org

Update: 32bit one is done uploading, and 64bit one too.

[bitbytebit]

Great! I'll test it this evening! Thank you very much for doing this. Just one question: is it set for D9800 or can I set it up to work with H9100? I understand that the script you posted above is for the case when it's installed, not for the livecd, isn't it?

I have good news with Catalyst 9.3. After some days messing with it and many blue screens I've been able to patch it so now I have a version that supports up to 137 custom modelines (it was limited to 60) and have removed the problem of hardcoded doublescan with 320x and 400x resolutions.

But the most important is that we have dynamic modelines with this Catalyst too. I've been investigating this dynamic stuff and have found that it's probably been there all the time, so there's no need to do any patching to achieve it. However, for some reason it only works when we have more than 16 custom resolutions defined. There's something else I've seen: in order to force the driver to read the modelines without restarting the system, it seems we only need to call the EnumDisplaySettings API, so it makes things easier than the twisted method I posted before in this thread. In fact that method only worked because it was using EnumDisplaySettings at some point, so the rest of it was just unnecessary. So this can be the key to have dynamic modelines in Windows for the newer ATI cards (up to 4000 family only). Unfortunately, we can't define new modes on the fly, only modify the existing ones, that's why it's important to have more than 60 modes in order to organize a decent precalculated mode table, I think that 137 can be good enough to store the variety of Mame resolutions if we ignore vfreq (later when running Switchres we will set those resolutions to their right vfreq in each case). So it won't be so clean as the way you use in Linux, as this precalculated table is not fully dynamic, and it will need some coding overhead, but the results can be just as good.

I still need to do a lot of tests with this. I've also want to test this with HD4350 I've just received, as by now all the test have been done with a X300.

The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.


Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.

[Calamity]

The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Modeline data is only supposed to be read by the driver, so no Windows programs, Mame, or even Windows itself ever reads that data, it's the driver that reads it and reports the labels as available video modes to the system. That's why all information that is used by the system API has integer values for everything, and the real vfreq values are not calculated ever, and are only the result of feeding the videocard hardware registers with modeline data, so there's no way Mame or AVres or MameResTool may know what the real vfreq will be, the only way is to read the registry and really perform the calculations as we are doing.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.

  I already had thought about that, indeed I intended to have a reserved mode named 1234x678, to do all dynamic stuff out of it! Unfortunately that's not possible. The problem is that from the system point of view, resolution labels are real. So if you have a 1234x678 label the system will reserve memory for that size, even if you define it internally as 320x240, and Mame will try center the frame (remember the problem we were having with xres increment loosing pixels on the right side).

Vfreq label is also important because if our monitor has an EDID, the system will filter the modes which vfreq is not supported by it. That's why I think we should use 60 Hz as a standard, because modes labeled with 50 Hz disappear when we connect a LCD.

Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.

Built in video modes are overridden by custom ones. So if you don't define any custom modeline for 800x600, you will be able to use the built in 800x600 vga modes, with several different vfreqs: 60, 70, 72, 100, etc (if your monitor has EDID the ones it doesn't support will be removed). But if you define a custom 800x600@60 modeline, it will override the native 800x600@60, the others will still be available (this is what happens with Catalyst 9.3, however with cat 6.5 all the other vfreqs where also overriden with our custom one! I believe it was a bug).

[Calamity]

BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.

[bitbytebit]

BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.

Yeah the boot up part to where it finally works, that's basically where Grub is running the show and uses BIOS Vesa modes.  That part we'll never be able to change, because Grub seems pretty hard to alter and it really doesn't have room I guess to put a lot of code in to do modelines so it just chooses BIOS ones till the Linux DRM layer kicks into play.  That's when things work for at least the first card, I'm not sure what is going on with the 4350 since that's the kind I'm using, really odd.  It's 32bit color for X Windows, and basically a 640x480 60Hz interlaced modeline generated with switchres using the CGA monitor type and put statically in the kernel headers.  So since the first card works, then it means it must be something odd with the second one and the DRM layer (my 4350 is a diamond one, maybe the branding version is different and another BIOS on it than mine?).  If you can attach another computer monitor to the other input, it would maybe help a lot seeing what the dmesg output is saying or /var/log/dmesg also is the bootup messages (less /var/log/dmesg) or just (dmesg) at the command prompt.  The DRM layer messages hopefully will say something interesting, I might need to have the livecd startup with networking enabled so you can ssh into it if it's hard to get the arcade monitor and a normal monitor working together.

 I think this sequence will allow you to access it with ssh possibly and start X Windows...

1. boot up (give it a while)
2. push enter
3. type eth0
4. push enter
5. At this point should be able to ssh into box, password for root is 'arcade'
6. push enter
7. push enter
8. type h9110
9. type 1
10 push enter

That should be the sequence, and allow both remote access with ssh to see dmesg output, and see if X Windows has any better luck at showing a display.  I get the feeling possibly the DRM layer is oops'ing or something weird, but hopefully not.

[Calamity]

I'll try that when I get home, my card is an ATI ASUS HD4350 PCX DDR2 HDMI SILENT, btw does your D9800 have an EDID?

[bitbytebit]

I'll try that when I get home, my card is an ATI ASUS HD4350 PCX DDR2 HDMI SILENT, btw does your D9800 have an EDID?

Nope it doesn't, which the DRM patch does expect no EDID else it would probably use the EDID  information as I'm guessing it should.  So in theory you should be able to hook up a normal monitor to the other port, and get both different, although the command line option for the kernel may override that somewhat.  Another option is to try with both your cards in the system and boot up trying either/or for attaching the arcade monitor and another, see if we can get the system information of what is going on in the logs from doing that, although hopefully the remote ssh or a monitor on the second port also works.

[bitbytebit]

The new version of Switchres now looks at the real information inside the modeline instead of the label.  I realized when working on figuring out what the actual modeline data was, that the labels mean nothing, and were not even always the real heightxwidth as the active lines (my 31.5Khz Soft15Khz 1024x768 only has 600 active vertical lines set it seems).  So that makes it ready for being able to go through and look at the modelines, instead of the labels like it was doing.  I'm guessing running some sort of --init to populate all available modeline slots with dummy modelines (which now I'm guessing they really don't even matter what they are saying they are in the label, or does mame really look at that even?), then alter them before starting the game to match the game.

Modeline data is only supposed to be read by the driver, so no Windows programs, Mame, or even Windows itself ever reads that data, it's the driver that reads it and reports the labels as available video modes to the system. That's why all information that is used by the system API has integer values for everything, and the real vfreq values are not calculated ever, and are only the result of feeding the videocard hardware registers with modeline data, so there's no way Mame or AVres or MameResTool may know what the real vfreq will be, the only way is to read the registry and really perform the calculations as we are doing.

Actually if mame really looked at the active lines instead of the label, why not just have 1 modeline (well over 16 to kick in the autoreload) and just that one we alter and the other 16 can be way crazy ones like 1024x768 that no game would ever use.  So it'd be just like in Linux where there's only one modeline to choose from anyways.  Also with that, disable all the normal modelines, can't we do that?  and then it'd force mame to pick the one we setup, and have a basic desktop modeline with 648x480 possibly for the desk top as we do in X Windows currently.

  I already had thought about that, indeed I intended to have a reserved mode named 1234x678, to do all dynamic stuff out of it! Unfortunately that's not possible. The problem is that from the system point of view, resolution labels are real. So if you have a 1234x678 label the system will reserve memory for that size, even if you define it internally as 320x240, and Mame will try center the frame (remember the problem we were having with xres increment loosing pixels on the right side).

Vfreq label is also important because if our monitor has an EDID, the system will filter the modes which vfreq is not supported by it. That's why I think we should use 60 Hz as a standard, because modes labeled with 50 Hz disappear when we connect a LCD.

Also is there any interaction between the active/official modelines and the custom ones, or are they totally separate from each other?  Basically after reboot, our custom ones don't also show up in the active list do they?  Something I am not fully sure of how that exactly works.

Built in video modes are overridden by custom ones. So if you don't define any custom modeline for 800x600, you will be able to use the built in 800x600 vga modes, with several different vfreqs: 60, 70, 72, 100, etc (if your monitor has EDID the ones it doesn't support will be removed). But if you define a custom 800x600@60 modeline, it will override the native 800x600@60, the others will still be available (this is what happens with Catalyst 9.3, however with cat 6.5 all the other vfreqs where also overriden with our custom one! I believe it was a bug).

Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.  Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?  I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.  If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others. 

That did sound too good to be true, able to only use one main modeline.  Sounds easy though to override the built in modelines since if one exists that overlaps it sounds like it won't matter and use our custom one.

[Calamity]

Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.

Yes that's it.

Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?

I guess that wouldn't work as you still need to call DirectDraw from Mame to do mode switching, and ddraw would create a framebuffer of the fake label size instead of the real one.

I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.

Yes, we would need to get a list of needed modes parsing Mame.xml and ignoring vfreq value, then add a list of other emulators we want to have (that's the idea behind this ReslList.txt file I use), and see if we can keep it lower than our top number of modes. We would need some kind of normalizing of values in order to get a shorter list, probably starting with yres. This is not a problem with Mame but some emulators insist to do a dirty stretching when you give them a resolution with extra lines, so we should be able to preserve the original resolution in some cases to avoid that.

If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others.

It's seems this is the way that driver developers have figured out to introduce modeline support in Windows. Unfortunately they decided that no one would ever need more than 60 custom video modes.

[bitbytebit]

Ah so basically I need to read it to know what it actually is, but use the label for the mame command line to direct it to use that specific modeline.

Yes that's it.

I've just fixed it so it should use the label, but yet choose by what the actual modeline is. Also now am storing the modeline data pretty much like you did, so am prepared to be able to alter any modelines seen.  My idea to make it simplest, would be to have Soft15khz be our vehicle to setup usermodes for us as the 60+ ones we have to work with.  So it can take care of dealing with all the initial setup, then past that we just fiddle with the modelines we see in switchres tuning/tweaking them to what we need. 

I had actually pretty much created a way to generate lists of the resolutions in lrmc that way pretty good, but using this modeline generator of course is needed since the generation of the list depends most likely on the monitor type and modeline generator we are using, to know what is possible and what we'll get for each game/system (using mess for the others besides mame).  I'll look at that, since creating an option to generate a usermodes.txt file for Soft15khz to input, then enabling write back to the modelines in the registry to change values to what we need, all sounds like it'll be possible pretty quickly.   

Can see the change I did in the git on sourceforge, which now is always going to be current by the minute updated since I'm using that for my GIT repository now.  I've been pretty happy with getting this all merged into one repository, which if you've not noticed now switchres source and the liveCD build script stuff is all basically together to keep things synced and simple for me to update easier.  Also now to get the base source of the livecd build git snapshots are the only option, possibly will eventually make just Windows builds and all linux/source downloads be from GIT like this.  Am slowly moving into the sourceforge site completely since it has all the space and git repository access, pretty amazing I can upload the .iso images there, I don't even know if they have a storage limit, at least anything I'd ever hit.

Commit:
http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=commitdiff;h=4f71e754c435882ce13e720ce1b9c80308b5032c;hp=090c47b4bde46f4e069dc31ffe32817866f0b58a

Source snapshot:
http://gentooarcade.git.sourceforge.net/git/gitweb.cgi?p=gentooarcade/gentooarcade;a=snapshot;h=refs/heads/master;sf=tgz

Although since giving mame that size won't it not fit, if they are smaller in actual active line sizes in the actual modeline?

I guess that wouldn't work as you still need to call DirectDraw from Mame to do mode switching, and ddraw would create a framebuffer of the fake label size instead of the real one.

I guess that's where needing the 60+ modelines comes in, to match everything as exact as possible with HxW to allow the match and size of mame display to both work right.

Yes, we would need to get a list of needed modes parsing Mame.xml and ignoring vfreq value, then add a list of other emulators we want to have (that's the idea behind this ReslList.txt file I use), and see if we can keep it lower than our top number of modes. We would need some kind of normalizing of values in order to get a shorter list, probably starting with yres. This is not a problem with Mame but some emulators insist to do a dirty stretching when you give them a resolution with extra lines, so we should be able to preserve the original resolution in some cases to avoid that.

If only it worked like in Linux and actually looked at the active parts, seems like this modeline thing and the label for them just has allowed for software to not be consistent since some look at labels, some at actual real active line information.  I now almost think the idea of having labels for modelines was a bad idea, should have always just been the raw modeline only and have that speak for itself.  It just gets way too messy all the combinations of modeline name/label formats and then how different parts of each system parses that or doesn't look at that or does look at it on some levels but not others.

It's seems this is the way that driver developers have figured out to introduce modeline support in Windows. Unfortunately they decided that no one would ever need more than 60 custom video modes.

[Calamity]

That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

BTW I've seen you using "dvi" commands somewhere with your grub line, could that make any difference in my case?

[bitbytebit]

That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

BTW I've seen you using "dvi" commands somewhere with your grub line, could that make any difference in my case?

No since that just specifies to only do that mode on one single interface, and without it the output is on all interfaces (which I don't have any specified on the liveCD, so it will output the same to all interfaces).  There are checks though that say if an EDID is found it'll use those modes, so should allow combinations of arcade monitors and normal ones together.  So it basically should be the same as it was for the other monitor, although you could try either output of the video card since there's no restrictions on which you use, whatever is plugged in will get the output and be the default if there's only one even if it's the second (unlike how Windows works I guess).

[bitbytebit]

That sourceforge thing looks really cool! I didn't know that could be done. Using soft15KHz for this is a good thing as it will open this to more video cards. However I don't know if other cards (non Ati) will allow dynamic modelines.

I wonder why that enum active function call reloads them if there's over a certain number, and if it does that for all drivers possibly or not.  Do the other drivers use different registry keys and methods for storing extra custom modelines?  Well at least it'll all work for ATI and other cards at least can manually load up Soft15khz with anything extra and reboot as they do now.  Under Linux it's questionable if other cards besides ATI ones will work well right now and allow both modeswitching with xrandr and vsync with OpenGL.  Seems like ATI is the current opening that mostly is ready, but every other video card driver is being worked on just about to use KMS and the OpenGL vsync stuff.  So it's all very promising in the future, I suspect the Nvidia cards are going to work well pretty soon, they might work now with the current build even, I have support for them but don't know if it works or not.  OpenGL doesn't like to play with Intel cards, have to use software video for that it seems for some reason (may be that I compile openGL and libdri on a system with a Radeon and it knows, need to look into that more).  It may just be the maturity of  OpenGL and DRM/KMS is not ready for Intel cards, it should be though for Nvidia Nouveau DRM/KMS though, just needs testing and maybe I need to tweak the dotclock limits lower for those too in the kernel patch eventually (but would be interesting to see if it just can modeswitch and vsync right now). 

[Calamity]

I wonder why that enum active function call reloads them if there's over a certain number, and if it does that for all drivers possibly or not.  Do the other drivers use different registry keys and methods for storing extra custom modelines?

I also wonder why, it might even not be supposed to do so. I have the feeling all the time that this is an unexpected property that might suddendly vanish on us. I'm almost sure it won't work with other drivers. Unfortunately each driver uses it's own format for modelines, so this one is only for Catalyst (the newer ones), so it's a good idea to have Soft-15Khz deal with that.

[bitbytebit]

BTW I've finally tested HD4350 with my Cat 9.3 patched drivers, and it works flawlessly it seems. I have to connect it using the dvi with a dvi-vga adapter, otherwise I get no video, as dvi is defined as primary device in these cards. The number of total video modes is way lower than the number I was using with 6.5, so I don't get such good results with a static mode table as before. However, the aim is to get dynamic modelines with this, so it's not so important after all. Native bios modes have a slightly different frequency to the ones from previous Radeon, so even if jpac allows me to have a readable split screen during system boot, the picture is badly distorted. So I will try to have these new patched drivers ready to download for this weekend.

I have also tested your livecd in my 2 cabs:

- With ArcadeVGA 9250, I can see the boot with a perfect progressive mode (AVGA Bios), then select CGA monitor, video mode switches to what seems 640x480 31 KHz (problem I believe), split screen but still can see the system prompting stuff, then we reach the part were I select monitor, mount drive, etc. and start X-Windows, with a perfect 640x480 interlaced mode, and I think it's 32 bits color as the icons look good, although I am not sure (if it was 4 bits it would mean it's a bios mode, bad). Unfortunately, I didn't have a mouse to use around the cab in that house, so I couldn't get to click to Wahcade and try anything, but it seemed to work.

- With HD4350, unfortunately I get no video right before the part where we're asked to select monitor, mount drives and stuff, so I can't see those menus, I know the system is not locked as I still hear the cd when I choose random options from my keyboard (no picture) but haven't managed to make it load X-Windows. The boot is also difficult to see as I have that distorted picture I mentioned before, but that's not the problem. I've tried to choose from the different modes for the console at the firt menu, but nothing changes. I've also tried to start the cab either with the monitor plugged to the vga or the dvi outs, without success. I suspect of the damned EDID issue.

On the other hand, I've seen the menus and stuff and I find it clean and nice to work with, hopefully we will be able to solve those problems.

Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

Code: [Select]

+static struct drm_display_mode drm_cga_modes[] = {
+       /* 640x480@60.000 */
+       { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 13004, 640, 664,
+                  728, 832, 0, 480, 482, 488, 521, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+       /* 800x600@49.06 */
+       { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 16353, 800, 832,
+                  912, 1040, 0, 600, 602, 608, 641, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+       /* 1024@768@40.54 */
+       { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 21806, 1024, 1072,
+                  1176, 1320, 0, 768, 774, 780, 815, 0,
+                  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
+                       DRM_MODE_FLAG_INTERLACE) },
+};




[Calamity]

Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...

[bitbytebit]

Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...

Oh, it's split screen all the way till you start X Windows?  It should be split up to a point of the boot messages, until it gets to the udev startup stuff, but past that is when the DRM modeline *should* kick in.  Odd if it isn't, guess it could be ignoring the interlacing but not sure why it'd do that.  Seeing the output of `dmesg` command and /the /var/log/dmesg file contents might help though, since the drm stuff is pretty verbose right now in the kernel messages so it very likely would tell me more.  I am thinking of making another build that perhaps only will output something like 320x240 at 15Khz to not need interlacing and hardwire it for the most part to that, maybe also enable some more debug messages for the dmesg output too. 

Could it be that the bootup part to the point of switching into DRM mode throws the monitor into an odd state somehow, since up to that point in boot up it's definitely some vesa based bios mode that grub uses to get things going.

[bitbytebit]

Is it a different monitor for each, is it possible the 640x480 modeline works on one but not the other?  I'm thinking of recreating that modeline, here's what it is right now...

No, it's the exact same Hantarex MTC 9110, until last week both cabs had an AVGA 9250 in them, now one has the HD4350, so it's a good way to test both generations of cards. I know that the modeline is not being used at all (at least outside X Windows) cause I have a split screen, which means that it's a 31 KHz signal being filtered by the jpac board, and I'm seeing the same thing with both cabs, I can barely read the texts thanks to jpac. If the modeline was being used but somewhat out of the monitor range I would be easy to know, but that's not the case... well, just a moment: I need to check if interlace is being activated despite the split screen with my former cab: that would mean your modeline is partially considered but its hfreq is ignored...

I am going to try and use a hopefully better strategy to how the kernel/X Windows stuff works.  It sounds like I should probably have 2 boot modes, just CGA or VGA and use 320x240 for CGA or 640x480 for VGA (possibly a 3rd SVGA where I don't pass any extra command arg to the kernel).  With that, I am thinking of a way to improve how the whole EDID check works in the kernel to make sure it's not somehow altering the choice of CGA or VGA mode.  I'm not sure what it's doing, but if interlace isn't working for certain cards it's one thing or if possibly the DRM stuff is not working for certain ones that is another, or if it's somehow being tricked into thinking there is an EDID for certain cards somehow.  Also I'm going to update to 2.6.37-rc4 because there is some interesting changes they made that have to do with interlacing in the last week...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c49948f4bd39e27dd06a1cdb0c3743ca2a734f5e;hp=0ec80d645661dda50acd417bdfcb33df2e5dd31e

So that's suspicious, but also it's interesting that one of your cards works in the framebuffer mode and other doesn't?  Or do they both do the same thing?  Since that change in the kernel seems like it might indicate something like what your seeing could occur depending on the type of outputs on the cards since they all vary in combinations of HDMI/VGA/DVI or whatever others there might be or subtypes of those I guess.

[Calamity]

I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:

1.- (using AVGA BIOS mode)


... and this is right after mode switching, sorry for the bad quality:

2.-


The one with HD4350, has split screen at point 1, and no video at all at point 2. It's connected via DVI-VGA (the 9250 is connected via VGA only). What makes me suspect of the EDID thing is that it seems this 4350 is really turning video off, no signal at all, it's not out of sync or anything. I'll try again with this one this evening, probably will plug the network cable to see if I can do ssh (no idea of what I should type however, I'll read the latests posts as it's probably been explained already).

Today I brought a mouse with me to test the first cab (9250) and finally was able to get into Wahcade. Video looks really nice inside X Windows. However, when I select a game, I expected some error message not finding the roms, but what happens is that X Windows exits to the console with an error message. By the way, during setup I mount /dev/sda1 as the roms drive but I can't figure out how to teach it to just point to C:\Roms\Mame.

[bitbytebit]

I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:

1.- (using AVGA BIOS mode)


... and this is right after mode switching, sorry for the bad quality:

2.-


The one with HD4350, has split screen at point 1, and no video at all at point 2. It's connected via DVI-VGA (the 9250 is connected via VGA only). What makes me suspect of the EDID thing is that it seems this 4350 is really turning video off, no signal at all, it's not out of sync or anything. I'll try again with this one this evening, probably will plug the network cable to see if I can do ssh (no idea of what I should type however, I'll read the latests posts as it's probably been explained already).

Today I brought a mouse with me to test the first cab (9250) and finally was able to get into Wahcade. Video looks really nice inside X Windows. However, when I select a game, I expected some error message not finding the roms, but what happens is that X Windows exits to the console with an error message. By the way, during setup I mount /dev/sda1 as the roms drive but I can't figure out how to teach it to just point to C:\Roms\Mame.

I think this sequence will allow you to access it with ssh possibly and start X Windows to look at the 4350 remotely...

1. boot up (give it a while)
2. push enter
3. type eth0
4. push enter
5. At this point should be able to ssh into box, password for root is 'arcade'
6. push enter
7. push enter
8. type h9110
9. type 1
10 push enter

you will want to look at possibly the output of the 'dmesg' command when your ssh'd into it (ssh root@IPADDRESS to access it, password above).  That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

 #  640x480@60.00 15.6300Khz
        ModeLine          "640x480x60.00" 13.004160 640 664 728 832 480 482 488 521 -HSync -VSync interlace

Although in theory it's the same as in X Windows so if that works then somehow the DRM layer is messing with the console video for the frame buffer I'm guessing.  Possibly I need to use 320x240 I guess because it avoids interlace and maybe the frame buffer just isn't great at interlaced modelines, hopefully 320x240 is safe.  Is there any better modeline resolution you think would be a good console one without any interlacing?

on the 9200 box, you can when in the console after it crashes, check /var/log/Xorg.0.log by running (less /var/log/Xorg.0.log) first of course choosing the menu option for the command prompt, and possibly see what is going on there.  If you have network access possibly sending me that file, transfering it to another system with (ssh -rC /var/log/Xorg.0.log user@system:) first. 

The rom directory probably doesn't have to be mounted/mapped for now to test because I have the default free roms from mamedev there right now to test with, but if you do map a drive it looks in the roms directory on that drive (so /data/roms/, where your drive is mapped to /data/).  I have a new layout file showing the layout in the GIT repository I just uploaded and also am starting to get support for configuring links to where ever the actual roms/artwork is and lnking it properly.  Here's the basic layout of /data/ right now that Wahcade looks at...


#
# Default directory layout for WahCade
#
## ROMS
/data/artwork_all
/data/samples
/data/roms
/data/biosroms
/data/Games/NES
/data/Games/SNES
/data/Games/Coleco
/data/Games/N64
/data/Games/C64
/data/Games/Atari2600
/data/Games/SegaGenesis
#
## Snap shots
/data/screen_shots/NES/snaps
/data/screen_shots/SNES/snaps
/data/screen_shots/Coleco/snaps
/data/screen_shots/N64/snaps
/data/screen_shots/C64/snaps
/data/screen_shots/Atari2600/snaps
/data/screen_shots/SegaGenesis/snaps
## Mame control/info files
/data/ctl
## Mame snapshots
/data/mrq
/data/cab
/data/fly
/data/cat
/data/pcb
/data/ttl
/data/prv
/data/ico


I do have the configuration menu able now to save all the information entered upon new boots and even auto find the home directory chosen after it's been setup, and since the config is saved there, then can read that and probably just boot into X Windows after 1 setup.  I really would like to try and get away from using the console for anything but when your in console mode at first it's the root administrator user so it can do all the configuration from there, then I startup X Windows as the arcade user so it's non-privileged after that point.  I might figure out a way to do it though so in X Windows the configuration can be done although that gets into the issue of needing to know the monitor type first Definitely some tricky stuff to figure out with all that, but I am seeing it definitely harder to support card/arcade monitor/TV/monitor combinations than I had thought at first, and hopefully having a more basic generic console mode for at least Arcade monitors (and need ones for TV's in NTSC/PAL too) will make it work for both your cards (seems like that linux kernel change for interlacing might be to blame so getting away from interlaced consoles would be nice).

[bitbytebit]

I've taken some pictures of the boot, these is the cab with the ArcadeVGA 9250, right before mode switching:

Do these look like good modelines for the framebuffer?

Code: [Select]


# [CGA] switchres 320 240 60 --monitor h9110
#  320x240@60.00 15.6600Khz
        ModeLine          "320x240x60.00" 6.639840 320 336 368 424 240 242 245 261 -HSync -VSync

# [CGA] switchres 640 480 60 --monitor generic
#  640x480@60.00 15.7500Khz
        ModeLine          "640x480x60.00" 13.104000 640 664 728 832 480 484 490 525 -HSync -VSync interlace

# [NTSC] switchres 720 480 59.95 --monitor ntsc
#  720x480@59.95 15.7369Khz
        ModeLine          "720x480x59.95" 14.855610 720 752 824 944 480 484 490 525 -HSync -VSync interlace

# [PAL] switchres 768 576 50 --monitor pal
#  768x576@50.00 15.6250Khz
        ModeLine          "768x576x50.00" 15.625000 768 800 872 1000 576 582 588 625 -HSync -VSync interlace



When using the h9110 monitor type, it is slightly different but not sure if that would make a difference, I'm thinking though that the CGA without interlace in 320x240 mode might work though since avoids interlacing at least.  Seeing the dmesg though would be helpful to know how the DRM stuff is acting about the EDID, mine just spits out a bunch of stuff about an invalid EDID or empty one basically, all 0xFFFFFFFFF's basically.  

Code: [Select]


radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000001
[drm:radeon_atombios_connected_scratch_regs], CRT1 connected
[drm:radeon_atombios_connected_scratch_regs], DFP2 disconnected
[drm:drm_mode_getconnector], [CONNECTOR:17:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DVI-I-1]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000001
[drm:radeon_atombios_connected_scratch_regs], CRT1 connected
[drm:radeon_atombios_connected_scratch_regs], DFP2 disconnected
[drm:drm_mode_getconnector], [CONNECTOR:13:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1]
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000010
[drm:radeon_atombios_connected_scratch_regs], CRT2 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:13:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1]
[drm:radeon_atom_dac_detect], Bios 0 scratch 2 00000010
[drm:radeon_atombios_connected_scratch_regs], CRT2 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:VGA-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:15:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1]
[drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1] disconnected
[drm:drm_mode_getconnector], [CONNECTOR:15:?]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1]
[drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:HDMI Type A-1] disconnected





Update:

Ah just found a bug, where I transfered over the values for the h9110 wrong, did the same timing vertically as the cga definition, not sure if that is an issue...

Code: [Select]

diff --git a/build_iso.sh b/build_iso.sh
index 619b7cc..a72b14a 100755
--- a/build_iso.sh
+++ b/build_iso.sh
@@ -1,6 +1,6 @@
 #!/bin/bash

-export VERSION=1.01
+export VERSION=1.02rc1
 export LIVECD=`pwd`
 export DO32BIT=
 export TARGET=${LIVECD}/target
diff --git a/src/SwitchResC/monitor.c b/src/SwitchResC/monitor.c
index b6c6531..7ef3e8e 100644
--- a/src/SwitchResC/monitor.c
+++ b/src/SwitchResC/monitor.c
@@ -255,8 +255,8 @@ int SetMonitorMode(char *type, MonitorMode monitor[MAX_MODES]) {
                monitor[0].HsyncPulse  = 4.700;
                monitor[0].HbackPorch  = 8.000;
                monitor[0].VfrontPorch = 0.064;
-               monitor[0].VsyncPulse  = 0.192;
-               monitor[0].VbackPorch  = 1.024;
+               monitor[0].VsyncPulse  = 0.160;
+               monitor[0].VbackPorch  = 1.056;
                monitor[0].HsyncPolarity = 0;
                monitor[0].VsyncPolarity = 0;
                monitor[0].ActiveLinesLimit = 288;



Also I'm wondering if that's an issue, how the h9110 has a lower Hfreq range, not 15.725-15.750 like the generic cga monitor would have?   How does that work, I'm pretty sure the Soft15Khz modelines and ArcadeVGA ones all tune to 15.750 but in the definition for it it's lower than that...

[Calamity]

Perfect, that's some stuff to start tests with.

That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

 #  640x480@60.00 15.6300Khz
        ModeLine          "640x480x60.00" 13.004160 640 664 728 832 480 482 488 521 -HSync -VSync interlace

I'm almost sure those modelines are just ok, as the CGA ones you've posted, they should work fine with Hantarex. But it's not that: if you see the second picture it's not that it's off center, its duplicated, split screen as I'm using jpac, so it's a 31 KHz signal, so possibilities are DRM is reading 640x480 but using it's own timings.

[bitbytebit]

Perfect, that's some stuff to start tests with.

That's one issue but the other is concerning too with the video off center horizontally like that.  Is it possibly a bad modeline, it should be this...

 #  640x480@60.00 15.6300Khz
        ModeLine          "640x480x60.00" 13.004160 640 664 728 832 480 482 488 521 -HSync -VSync interlace

I'm almost sure those modelines are just ok, as the CGA ones you've posted, they should work fine with Hantarex. But it's not that: if you see the second picture it's not that it's off center, its duplicated, split screen as I'm using jpac, so it's a 31 KHz signal, so possibilities are DRM is reading 640x480 but using it's own timings.

Interesting, I am kind of suspecting this may be the AVGA bios issue because come to think of it that's what mine does actually.  That's the part I said about how it'll have really wild values for the refresh rate, like the programming of it in the DRM layer just doesn't do it right at all and it's just way off in setting the mode.  So for the AVGA card, that might be what's going on, similar to what mine does how it boots like it should with the AVGA bios but then when DRM kicks in it's all weird (since I have a d9800 I guess it doesn't double screen, it's just an odd odd mode setting with way high refresh rate and wrong horizontal freq). 

With the other card, split screen makes sense on boot, till the DRM layer, then it's breaking and maybe the DRM layer is crashing completely which is one possibility.  I'm not sure why that would occur, but it seems like the behavior that happens, possibly trying a normal monitor and seeing if it works on there and get some dmesg output.  I suspect it'd break on either one, Arcade or computer monitor, and might be some bug in the linux kernel ATOM bios code.

So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that). 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking.