Amiga.org
Operating System Specific Discussions => MorphOS => MorphOS -- Hardware requirements and availability discussion => Topic started by: Gulliver on August 17, 2011, 11:29:26 PM
-
I have recently come across a PowerMac Quicksilver 2002 and decided to give it a try with Morphos.
My setup:
Quicksilver 2002
256MB RAM
PATA HDD 80GB (Unpartitioned, tested working on another machine)
ATI gfx card
PS2 keyboard & PS2 mouse thru a PS2 to USB adapter
Morphos 2.7 properly burnt on a cdrom
I have a samsung 43" LCD TV that is connected thru VGA cable to the VGA port of the Ati gfx card in "PC compatible mode".
When I boot up the MOS cdrom starts and gives me this message:
Quark/Openfirmware
console failed
System: Rev <>
CPU0: Version 0x8000 Revision 0x201
CPU0: CPUClock 799999998 BUSClock 133160004
Then the screen goes black, some more cdrom activity is heard and my monitor yells unsupported resolution. And there ends my MOS experience with this PowerMac. :(
Can anyone help me figure out how to make it work?
-
When I boot up the MOS cdrom starts and gives me this message:
Quark/Openfirmware
console failed
System: Rev <>
CPU0: Version 0x8000 Revision 0x201
CPU0: CPUClock 799999998 BUSClock 133160004
Then the screen goes black, some more cdrom activity is heard and my monitor yells unsupported resolution. And there ends my MOS experience with this PowerMac. :(
Can anyone help me figure out how to make it work?
MorphOS DDC fails to generate compatible modes for some reason. There can be numerous reasons for this. Try holding down LMB or F1 while the system boots. If you get a bootmenu try to change the screenmode the system boots to. If this works you can continue with install and choose this screenmode for the system later on.
If LMB or F1 don't give you a visible bootmenu you'll need to try a different monitor.
-
Thanks, will do that and report back :)
-
Okay, thank you, it worked, after changing the montior to another one. I am posting this from the default OWB1.1 which will soon be updated to 1.9.
The thing is that my Radeon 7500 (32MB) seems to only manage upto 1024x600, and then again this "new" monitor wines about it saying that I should better use 1440x900 resolution, which seems unavailable to me from MorphOS :(
Is there a way to tweak the settings to make it work in that optimum resolution? At 1024x600 my eyes hurt, but at least I can see the entire desktop.
BTW I am usiong now an 19" LG model M198WA-BM
Any help is apreciuated.
-
Okay, thank you, it worked, after changing the montior to another one. I am posting this from the default OWB1.1 which will soon be updated to 1.9.
You should upgrade it to Odyssey 1.14:
http://fabportnawak.free.fr/owb/
The thing is that my Radeon 7500 (32MB) seems to only manage upto 1024x600, and then again this "new" monitor wines about it saying that I should better use 1440x900 resolution, which seems unavailable to me from MorphOS :(
32MB is well enough for these resolutions, but you might want to disable the eye candy:
Go to system preferences, Screens and then disable "Enhanced layers" for Ambient screen. This should help with systems with limited amount of VMEM.
Is there a way to tweak the settings to make it work in that optimum resolution?
It seems you're not having much luck with the DDC in MorphOS. Typically this stuff should work automagically.
It is possible to edit the screenmodes the old fashioned way. Go to system Preferences, then Monitors. Editing the modes is basically the same as with CyberGraphX CGXmode. You can create and test the 1440x900 mode there. After you've created the mode you need to reboot. To make Ambient use the mode you need to go to System preferences, Screens and set the Ambient mode there.
-
Okay, thank you, it worked, after changing the montior to another one. I am posting this from the default OWB1.1 which will soon be updated to 1.9.
Just a sidenote: 1.10 is included in MorphOS, not 1.1. So using 1.9 would actually be a downgrade. But as Piru said, use 1.14, anyway. :)
-
Just a sidenote: 1.10 is included in MorphOS, not 1.1. So using 1.9 would actually be a downgrade. But as Piru said, use 1.14, anyway. :)
If that's true, that's horrible and confusing versioning.
1.10 should always be = to 1.1
1.9 should always be > 1.14
-
If that's true, that's horrible and confusing versioning.
1.10 should always be = to 1.1
1.9 should always be > 1.14
nope. such versioning scheme is unamigan. it breaks version command for instance.
it's version dot revision and not some decimal number!
-
No idea what's "Amigan" or not, or what breaks what, just pointing out it is not logical and is confusing.
1.09 would be < 1.14
-
It's x.y (where x=version and y=revision).
So in the example 1.9 or 1.14 --> Version=1 and Revision=9 or Revision=14
Apparently 14>9 ! As Piru said... it's not simple decimal numbers.
-
No idea what's "Amigan" or not, or what breaks what, just pointing out it is not logical and is confusing.
1.09 would be < 1.14
No it's not confusing and it's perfectly logical. It's only confusing if you think version number as a decimal number, which it is not.
-
If that's true, that's horrible and confusing versioning.
1.10 should always be = to 1.1
1.9 should always be > 1.14
Well... linux often uses two dots in version numbers. Would you read that as decimals too? :)
-
It's confusing because in 99% of all cases, in the general software world, versioning is done using decimal. And when you use a decimal point, you're certainly implying that.
It's not confusing for you because you're familiar with the software. But, what if one piece of software uses decimal and the other does not? How does the user know which is which if both are presented in the same format and both use a decimal point?
If I'm a new user installing MorphOS and trying to download a piece of software and I see version 1.14 and version 1.9 I'm instinctively going to download 1.9.
I understand what you're saying, I'm just pointing out that it's confusing to the user. You can't use a decimal point and say it's not a decimal number and expect a typical user to just know that.
From a general perspective if it's version 1 revision 14, it should be labeled v1r14 not 1.14.
-
No it's not confusing and it's perfectly logical. It's only confusing if you think version number as a decimal number, which it is not.
People might be less prone to thinking of it as a decimal number if it weren't written like a decimal number ;P If, say, you kept the scheme but wrote it with a dash, nobody would confuse 1-5 for (3/2).
-
It's confusing because in 99% of all cases, in the general software world, versioning is done using decimal.
I disagree. Most of the software world uses version . revision [. build or and maybe even 4th element]. Even Microsoft does that (they may have used 1.04 or something as silly for Windows 1).
And when you use a decimal point, you're certainly implying that.
Nope, it's a common practice to separate the version components with a dot.
It's not confusing for you because you're familiar with the software. But, what if one piece of software uses decimal and the other does not? How does the user know which is which if both are presented in the same format and both use a decimal point?
There's no way to know. Decimal number is far less flexible and more confusing way to do it however, and thus it is used less and less.
If I'm a new user installing MorphOS and trying to download a piece of software and I see version 1.14 and version 1.9 I'm instinctively going to download 1.9.
Understandable mistake if you don't know that the version number isn't a decimal number in AmigaOS and MorphOS world.
I understand what you're saying, I'm just pointing out that it's confusing to the user. You can't use a decimal point and say it's not a decimal number and expect a typical user to just know that.
I'm under the impression that most if not all MorphOS users have prior experience with amigaos, and such understand that version numbers are not decimal numbers.
From a general perspective if it's version 1 revision 14, it should be labeled v1r14 not 1.14.
That'd be just even more confusing I'd say. My experience is that software using decimal versioning is nowadays quite rare. It does exists for sure, but is far less common than before.
-
People might be less prone to thinking of it as a decimal number if it weren't written like a decimal number ;P If, say, you kept the scheme but wrote it with a dash, nobody would confuse 1-5 for (3/2).
Just a quick note regarding this: not all countries use . as a decimal mark.
http://en.wikipedia.org/wiki/Decimal_mark#Hindu-Arabic_numeral_system
-
We'll have to agree to disagree.
There's no way to know. Decimal number is far less flexible and confusing way to do it however, and thus it is used less and less.
Are you saying decimal is more or less confusing? I find it less. And I don't see how it would be less flexible. You can simply pad with 0s, like:
1.09.05 and 1.14.06 which can be interpreted only 1 way
instead of 1.9.5 and 1.14.6 which can be interpreted 2 ways
-
instead of 1.9.5 and 1.14.6 which can be interpreted 2 ways
Not where I sit.
(Hint: 5/4 == 1,25)
-
We'll have to agree to disagree.
Agreed.
Are you saying decimal is more or less confusing?
More. I fixed it in the original post as well, thanks for pointing it out.
I don't see how it would be less flexible. You can simply pad with 0s, like:
1.09.05 and 1.14.06 which can be interpreted only 1 way
So it isn't a decimal number anymore but some strange way to group hundreds? Also what happens if revision gets more than 2 digits? How can you add extra 0s to the old version numbers to avoid confusion?
I'm sorry but this is just more confusing than using separate numbers for version, revision [,build etc].
-
@Gulliver
Any luck with creating the needed screenmode?
-
So it isn't a decimal number anymore but some strange way to group hundreds? Also what happens if revision gets more than 2 digits? How can you add extra 0s to the old version numbers to avoid confusion?
I'm sorry but this is just more confusing than using separate numbers for version, revision [,build etc].
If you anticipate it you pad additional 0s:
1.009.005
1.014.006
1.128.341
Or, add to it:
1.09.05
1.14.06
1.14.06.24
1.14.06.28
Type these into Excel and see how they sort:
1.9.5
1.14.6
1.22.8
Excel sees 1.14.6 as the lesser value.
I see the merit in both ways, but I think my preference is more straightforward. My evidence is Gulliver, who misunderstood as well.
-
If you anticipate it you pad additional 0s:
1.009.005
1.014.006
1.128.341
Eeek, now that's really ugly. :)
Type these into Excel and see how they sort:
1.9.5
1.14.6
1.22.8
Which just proves nothing. In this case it just does some alpha sort (or possibly decimal sort on the first part, but both are irrelevant)
I see the merit in both ways, but I think my preference is more straightforward. My evidence is Gulliver, who misunderstood as well.
Should we make a poll? And is there a theorem saying that when most people think something is right, it's true, or? :)
-
Eeek, now that's really ugly. :)
Whether it's pretty or ugly, it cannot be confused. Should a versioning scheme based around what is ugly or pretty?
Which just proves nothing. In this case it just does some alpha sort (or possibly decimal sort on the first part, but both are irrelevant)
Both - alpha and decimal will sort the same way. How can you not see the proof in that? It's mathematical. If I want to maintain a spreadsheet of my software builds, how exactly can I sort by version and get an accurate result?
Should we make a poll? And is there a theorem saying that when most people think something is right, it's true, or? :)
Polls are worthless. The point is not what people prefer, the point is which method would cause the least confusion.
Make a test. Give 100 people these numbers:
1.012.036
1.009.010
1.056.012
and
1.12.36
1.9.10
1.56.12
Ask all 100 people to sort both sets of numbers. See which scheme gets the highest % of proper sorting.
-
1.12.36
1.9.10
1.56.12
In a software industry it is always assumed 1.12 is newer than 1.9. There is no doubt about it. What users think is another thing and companies often market their products without version numbers or use simpler versioning scheme.
-
Most software I see avoids confusion by, for example, saying 6.01 instead of 6.1.
Or 6.1000 and going from there.
-
Thank you again Piru. I am trying right now with the service manual of the monitor to manually configure the "Monitors" preferences.
I guess you should see that the DDC code gets reworked, since both of my LCD monitors work beautifully with the Quicksilver on both on OSX and Linux ;)
I know the MOS experience is much better than this unfortunate monitor incident, that I am confident I will manage to solve with your help.
I will post back hopefully in a couple of minutes with a happy smile.
-
Update:
I went to Prefs->Monitors and selected New, then changed 8 bit to 24 bit. I raised the pixelclock till the upper end so that I that I could achieve higer resolution modes.
On Horizontal timing, by reducing the sync and pulse length I managed to achieve 1440 (which was my goal here).
On the Vertical timing despite tweaking the values I could not achieve anything higher than 624 resolution (900 is my goal here).
I am clueless :(
This are my monitor resolution values taken from the Service Manual:
6. RGB Input (PC)-M198WA
No Resolution H-freq(kHz) V-freq.(Hz) Pixel clock(MHz)
1 720*400 31.468 70.08 28.321
2 640*480 31.469 59.94 25.175
3 640*480 37.5 75 31.5
4 800*600 37.879 60.317 40.0
5 800*600 46.875 75.0 49.5
6 1024*768 48.363 60.0 65.0
7 1024*768 60.123 75.029 78.75
8 1152*864 67.500 75.000 108.0
9 1280*1024 63.981 60.02 108.0
10 1280*1024 79.976 75.035 135.0
11 1440*900 55.5 59.90 88.750
12 1440*900 55.935 59.887 106.50
13 1440*900 70.635 74.984 136.75
That manual with further technical information is available at:
http://archive.espec.ws/files/LG%20FLATRON%20monitor%20ch.LP69G%20%20%20M198WA,M228WA%20.pdf
-
With which monitor did you start ?
If your one wasn't detected by DCC it might have been stucked at a model with much lower specs (or even at the "Monitor-xxKHz").
Try to find a monitor from the list that is as close as possibles as yours, normally that should be enough and if it isn't work your way from there.
-
@Kronos
I started with a Samsung series 4+ 43" lcd TV PDP450, that didnt work with MorphOS from the install cdrom. It just showed some console failed message for a couple of seconds, and then nothing. Optimum resolution is 1024x768.
Then I switched, as suggested by Piru to another one, an LG 19" lcd model MW198WA-BM, which is the one that I am speaking about, that doesnt seem to work either at its optimum resolution of 1440x900.
And, as said before both support DDC and work beautifully under Linux and OSX on the same hardware (QS2002).
And they both work great with any x86 PC compatible I tried.
-
Odd, normally these modes just follow a simple norm.....
You might to try a monitor thats one size bigger (the usual 21" that will go to 1680x1050) and use the 1440x900 mode defined there.
Those things can be tricky .... just reminds me when I tried to get a 24" 16:10 running under 1.4.x (which only had 4:3 monitors predifined).
If your monitor has an analoge input (VGA or via DVI-VGA adapter) you might try it there 1st as most monitors are bit less picky on that side.
-
They were both always connected to their VGA input, directly from Radeon 7500 VGA output on the QS. From VGA to VGA with no adapters in between. :(
-
Bumpety boo