The 32bit version has uploaded to test.
Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?
The pixel clock is stored in khz units in the mode structs in the
|kernel and in X. We expand it to hz in the pll divider calculations.
|Then it's reduced to 10 Khz units for the atom methods, but at this
|point it doesn't matter as the pll dividers have already been
|calculated, so I don't think it's an issue.
I don't understand what 'atom methods' would require dotclock values once the pll dividers have been worked out, however we could check if we can add the extra digits when it's expanded into hz, right before the pll divider is calculated, and see if it makes any difference.
I'll test the new version in a while.
UPDATE: I've tested new version of liveCD 32, with HD4350, unfortunately with same results (black screen), have tested also 320x240 init mode but makes no difference. I can't see the arcade machine in the network now either. I'm starting to think that it's related to the card, not for it being faulty as it's working well, but for some reason the video is turned off when it reaches that point (DRM?), maybe for not detecting any monitor or whatever else, but it's interesting that the same code was more or less working with old AVGA 9250 (I tested liveCD 32 version 1) and same monitor. So I definitely need to test this stuff with the HD4350 plugged to a pc monitor to check if I have video with it. Unfortunately I don't have one around at this place where the cab is but will try to get one here soon.
Very odd that it isn't showing up even after X Windows starts, seems like the card is either only outputting video on one output or none of them after the DRM stuff kicks in. Yeah I took out the network startup actually for now since it slows down startup without it connected and also forces the network interface on in the config, I need to think more of a better way to enable that for the first config. It definitely would be good to see with a normal monitor what is going on, I am pretty sure what is happening has to do with the driver/card interaction and output video is possibly thinking the monitor isn't there, probably good otherwise if it'd only see the monitor connection. It is interesting, the log will most likely show the issue and I'm guessing the monitor detection for the connectors is for some reason not saying anything is attached. I'm working a newer .iso which I'll try to make sure there is a network setup for the ethernet interface, to ssh into the box and grab /var/log/messages and /var/log/dmesg and output for the `dmesg` command.
The next .iso I'm hopefully getting to do a few things, like have it ask you where the roms are, which you can now use one single home/data drive and it'll ask where each rom/snap directory is actually located and link it to the expected default location and do that on future boots. Also looking into being able to install this onto the hard drive, I think it might not be that difficult so it'll be both a liveCD and installation CD too. Need to make a menu option when unformatted drives are seen to actually partition and format them, so can really get the partitions setup from scratch.
There's something interesting too, the page flipping support for all Radeon cards is coming very soon, in 2.6.38 but is already in the GIT stuff and the Alex guy showed me the places to get that so I'll hopefully be able to build that in soon too...
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?h=kms-pflip&id=69639ef377a9d6701cdef902f8a1c5e0b58cf833Is that monitor any different with the VGA connection than possibly the d9800? It seems that what is going on, I suspect, is the DRM connector checking doesn't see it and turns it off. We could in theory force it on, with xrandr possibly or at the linux boot prompt I can specify it to always be on too for DRM outputs. Actually once I get a version up with ssh access enabled, you can do this from another system and send me those files...
scp -rC root@arcadesystem:/var/log/messages messages
scp -rC root@arcadesystem:/var/log/dmesg dmesg
ssh root@arcadesystem (then when in type dmesg > dmesg.log)
scp -rC root@arcadesystem:/root/dmesg.log dmesg.log
Using `arcade` as the password.
Also the person using the PAL TV seemed to not be able to use the 640x480 default we had, but it does work with the PAL DRM modeline I put in there, so something interesting, I think I have it now setup where it'll go into X Windows to setup also using that same modeline if the PAL option is chosen at the boot prompt (odd that the boot prompt shows up, not sure why that is for sure).