19-Apr-2024 00:06 GMT.
UNDER CONSTRUCTION
Anonymous, there are 50 items in your selection
[Events] DC Pegasos Show Mini-ReportANN.lu
Posted on 19-Oct-2003 01:33 GMT by Daniel Miller50 comments
View flat
View list
MorphOS, Linux, AmiNetRadio, FxPaint, MPlayer, Kaya, ImageFX, free Superbundles, fresh MOS1.4 CDs with IBM stamp, ProStationAudio, presentations, the "VCR" case, complete system pricings, Peg II picture, MOS1.5 timing, MadBomber, and more. From start to finish this was a really classy affair. I am local to the area and was invited to bring and show my own Pegasos, but this didn't stop me from checking out the scene and watching the presentations. Genesi personnel were really on a mission, giving personal attention, and striving to show the technology at its mindblowing best.

The chief exhibitor was magneticsystemsnyc.com who drove down from Brooklyn with a squad of state-of-the-art Pegasoses, including one of the few G4 models we have on this side of the pond. Four of those systems were configured for MorphOS, the fifth did double duty as an MoL/Debian (Gnome) machine. In addition to my comparatively home-spun system, there was a nice array of Genesi paraphenalia such as a plexuscom concept case, spinning illuminated Peg motherboards, a mechanical butterfly, a sampling of shrinkwrapped games, a Catweasel flipper for display, posters, sellsheets, free Superbundle (v. 3) and MOS1.4 IBM stamp limited silk screen edition CDs. Jammin'!

Now the stuff was neat, and the people were neater, but I must say seeing the cutting edge MOS systems in action was even more neat than that. It was... neat-o! Where to start? well, one of the more striking things was AmiNetRadio. As much as anything else this really illustrated one aspect of the future as Genesi sees it. The live radio stations scroll down in a list, and you select your favorite genre. It very quickly picks up the stream and your music plays. Most streams were at 128, some at 64, so this is fairly high fidelity. You can record your streams to MP3 files on your hard-drive, and them play them in Kaya. This all occurs effortlessly. Why does this illustrate part of Genesi's vision? They see themselves providing media, audio, visual, audiovisual and games via similar tools. Customers are then able to access their favorite media whether they are on walking trails with the planned Eclipsis handheld device, in their homes at their home theater, or at their workplace, whatever. You don't carry around a CD or plunk a videotape in the VCR, you just select your media on whatever device you are nearest and play it. Genesi believes that all this media including high resolution movies will be deliverable as the Pegaos progresses and new Genesi products are introduced. So that's the concept, maybe you like it, maybe you love it.

Another concept, this one now reality, is the "VCR" Pegasos. This was introduced by magneticsystemsnyc.com. What is it? It's a Pegasos in a small case that looks sort of like a VCR. This is offered as a complete Pegasos II system. If you don't want to muck around with assembling your own, you can consider getting one of these. It's nice and uses a half height Radeon video card. I like this, because it is an early step in the shrink-down evolution of Pegasos from standard desktop to set-top box to the handheld computer which is conceptualized to have all the power of a Pegasos.

Bill and Raquel from Genesi were there, as always demonstrating their personal commitment to the platform and its development, and supporting the rest of the Genesi team working towards the goal of a advanced, mature, popular, modern, alternative computer system.

More software: MPlayer was all over the frickin' place. People who demonstrated this system have recognized a winner. On just a G3 600 Mhz Pegasos running MorphOS 1.4 Mplayer is the most quickloading, responsive, compatible videoplayer ever on any platform. I am not spinning you, everybody says this. We all need to send the Mplayer programmers five dollars right now or something. There are few sublime pleasures in life as the first time you starting moving an MPlayer window opaquely around the screen, and realize that there is zero stutter or distortion, no matter how fast you circle it around. Hi-res letterbox or whatever. Of course it goes full screen and has a bunch of control features too.

There was some new image editing software from NovaDesign shown. They make well-established graphical prodcuts like ImageFX and Aladdin 4D. I was not clear on the details, but there is the intention to offer some form of this new software with future MorphOS versions, the Superbundle, or both. This is a clear potential asset to the Pegasos MorphOS product. The prospect of a revamped Aladdin4D ray tracing program for MOS was also talked about. ProStationAudio was shown. This is a really advanced sort of product with a detailed, intricate interface and all these channels and mixing controls and a lot of busy stuff going on all over the screen. It was shown mixing some tracks and certainly sounded good. It seems to me that this is a product for an audio professional, but maybe a casual home user can have fun with it too. Gotta go, I will have to write some more later, especially about... MadBomber!!!

PS: The BB half of BBRV stated MorphOS 1.5 would appear before the new year. Don't let them forget about that TCP-IP stack, thanks.

DC Pegasos Show Mini-Report : Comment 1 of 50ANN.lu
Posted by Anonymous on 18-Oct-2003 23:49 GMT
Nice report, thanks! Good to know that the Pegasos has the power for on-the-fly video encoding, I always wanted to do that with mine.
DC Pegasos Show Mini-Report : Comment 2 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 02:51 GMT
In reply to Comment 1 (Anonymous):
> Nice report, thanks! Good to know that the Pegasos has the power
> for on-the-fly video encoding, I always wanted to do that with
> mine.

Not to rain on things, but where did it say anything about encoding?

As to the power required, and ways to work around the need for it, these seem to offer some insight:
http://www.mythtv.org/docs/mythtv-HOWTO-10.html#ss10.5
http://tinyurl.com/rgmw (TinyURL to Google cache of an expired link...)
http://thegoods.ath.cx/~hmason/macdvd2divx/ (MPEG2->DIVX numbers on MacPPC)

I haven't followed the design of existing PVRs, but with today's disks as big as they are, I imagine you could capture in mjpeg and transcode in the background without losing too much capacity. Altivec and/or GPU accelerations reducing the decoding load might negate the need.

A little Googling shows Tivo gets by with far, far less (66MHz PowerPC 403GCX?), but it has one of these guys doing the hard work - http://tivo.samba.org/download/tridge/dec-cs22-usrapgd.pdf - and presumably a similar assist on the encoding end. (There are plenty of chipsets out today that'll take video in and spit MPEG out; having looked at USB TV adapters, that's what most of them offer, though the quality from 1.x devices isn't said to be stellar.)

It'll be interesting to see what cooks up, of course.
DC Pegasos Show Mini-Report : Comment 3 of 50ANN.lu
Posted by opi on 19-Oct-2003 03:46 GMT
Thanks for this raport. It was nice read.
DC Pegasos Show Mini-Report : Comment 4 of 50ANN.lu
Posted by hooligan/dcs on 19-Oct-2003 07:45 GMT
>PS: The BB half of BBRV stated MorphOS 1.5 would appear before the new year. Don't let them forget about that TCP-IP stack, thanks.

Pegasos2 needs an updated MorphOS, 1.5 or an update to 1.4. Does this mean no Pegasos2 till the end of year?
DC Pegasos Show Mini-Report : Comment 5 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 08:18 GMT
"one of the more striking things was AmiNetRadio. As much as anything else this really illustrated one aspect of the future as Genesi sees it. The live radio stations scroll down in a list, and you select your favorite genre. It very quickly picks up the stream and your music plays."

This works really well on my Amithlon setup, too. Excellent program.
DC Pegasos Show Mini-Report : Comment 6 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 08:21 GMT
In reply to Comment 4 (hooligan/dcs):
"Pegasos2 needs an updated MorphOS, 1.5 or an update to 1.4. "

Why?
DC Pegasos Show Mini-Report : Comment 7 of 50ANN.lu
Posted by hooligan/dcs on 19-Oct-2003 08:45 GMT
In reply to Comment 6 (Don Cox):
I told you already in another thread.
New northbridge and 1gb ethernet requires drivers.
DC Pegasos Show Mini-Report : Comment 8 of 50ANN.lu
Posted by 3seas on 19-Oct-2003 09:10 GMT
Remember People, the focus is on selling hardware. This makes applications important only in the since of what you can do with the hardware.... currently..

Being able to play radio stations on your computer is certainly nothing new.... and is dependant upon your connection speed and network status...etc.
DC Pegasos Show Mini-Report : Comment 9 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 09:24 GMT
In reply to Comment 7 (hooligan/dcs):
You do _not_ need drivers within the OS for the bridge chips. These are handled in the BIOS, which on the Pegasos boards is I believe Open Firmware.

MorphOS would run unchanged.
DC Pegasos Show Mini-Report : Comment 10 of 50ANN.lu
Posted by hooligan/dcs on 19-Oct-2003 09:39 GMT
In reply to Comment 9 (Don Cox):
If that is the case, then I've been lied to by a MorphOS developer.
DC Pegasos Show Mini-Report : Comment 11 of 50ANN.lu
Posted by Daniel Miller on 19-Oct-2003 09:50 GMT
In reply to Comment 10 (hooligan/dcs):
No way Hooligan, I am sure nobody did that. There must be a lot of stuff in MorphOS that must be adapted to the Marvell.
DC Pegasos Show Mini-Report : Comment 12 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 10:05 GMT
In reply to Comment 11 (Daniel Miller):
"There must be a lot of stuff in MorphOS that must be adapted to the Marvell."

I can't see why. MorphOS can't even start to run without loading from disk to RAM. You can't do that unless the bridge chips are already working.

You don't need a different version of Windows or Linux for motherboards with different chipsets. The chipset is at a lower level than a disk-based OS. It has to be set up by code in a ROM.

If I am wrong, I'm sure Ralph Schmitt will correct me.
DC Pegasos Show Mini-Report : Comment 13 of 50ANN.lu
Posted by itix on 19-Oct-2003 10:05 GMT
In reply to Comment 9 (Don Cox):
> You do _not_ need drivers within the OS for the bridge chips. These are handled in the BIOS, which on the Pegasos boards is I believe Open Firmware. SANA-2 driver for gigabit ethernet is needed, maybe some other stuff too...
DC Pegasos Show Mini-Report : Comment 14 of 50ANN.lu
Posted by Kronos on 19-Oct-2003 10:11 GMT
In reply to Comment 12 (Don Cox):
@Don

Don't forget that every x86 will start mimicing an ancient IBM-AT, and only after the
basic boot is done the OS will load drivers/set the chipset to get better performance.

I don't think there is such a common ground for PPC-NBs, or otherwise it would be
dead-easy to boot MacOS on a Peg(without MOL) or MorphOS on a Mac.
DC Pegasos Show Mini-Report : Comment 15 of 50ANN.lu
Posted by Anonymous on 19-Oct-2003 10:14 GMT
In reply to Comment 2 (Joe "Floid" Kanowitz):
>Not to rain on things, but where did it say anything about encoding?

I was assuming that VCR Pegasos means that it's designed to be used as digital VCR, like this: http://www.tldp.org/HOWTO/VCR-HOWTO.html. A table there says that a 875mhz Duron is fast enough, so I wouldn't expect problems with the G4@1GHz anyway, especially under light weight MorphOS. But I'm curious about the G3 at 600 MHz.
DC Pegasos Show Mini-Report : Comment 16 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 10:34 GMT
In reply to Comment 8 (3seas):
"Being able to play radio stations on your computer is certainly nothing new.... and is dependant upon your connection speed and network status...etc."

But AmiNet Radio does it particularly well.
DC Pegasos Show Mini-Report : Comment 17 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 10:38 GMT
In reply to Comment 13 (itix):
"SANA-2 driver for gigabit ethernet is needed, maybe some other stuff too..."

That's different. Even then, the old driver would probably work at low speeds.
Likewise, you would need a driver for a new sound card. These are all things on the PCI bus.

The claim was that changing the bridge chip would need changes in the disk-based OS.
DC Pegasos Show Mini-Report : Comment 18 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 10:51 GMT
In reply to Comment 14 (Kronos):
"Don't forget that every x86 will start mimicing an ancient IBM-AT, and only after the
basic boot is done the OS will load drivers/set the chipset to get better performance."

This is because Microsoft (and the Linux community) don't write the BIOS. The Genesi people write their own BIOS, so they can do all the setup there, where it should be done.
DC Pegasos Show Mini-Report : Comment 19 of 50ANN.lu
Posted by Daniel Miller on 19-Oct-2003 10:51 GMT
In reply to Comment 15 (Anonymous):
> I was assuming that VCR Pegasos means that it's designed to be used
> as digital VCR...

No, it is just the style and small size of the case that cause it to be referred to as "VCR." That is a bit confusing, sorry. It's a standard Pegasos in the case.
DC Pegasos Show Mini-Report : Comment 20 of 50ANN.lu
Posted by Johan Rönnblom on 19-Oct-2003 11:19 GMT
Uh, just because some driver or another would be added or updated,
doesn't mean you have to move from MOS1.4 to 1.5. Small updates for
libraries, devices etc happen all the time.. no big deal.
DC Pegasos Show Mini-Report : Comment 21 of 50ANN.lu
Posted by hooligan/dcs on 19-Oct-2003 11:37 GMT
In reply to Comment 20 (Johan Rönnblom):
Hence the, quote,: "update to 1.4" (=1.41 for example)
DC Pegasos Show Mini-Report : Comment 22 of 50ANN.lu
Posted by Anonymous on 19-Oct-2003 11:57 GMT
In reply to Comment 21 (hooligan/dcs):
That would mean they jumped 37 revisions.
1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11 ... 1.20 ... 1.30 ... 1.40, 1,41
DC Pegasos Show Mini-Report : Comment 23 of 50ANN.lu
Posted by hooligan/dcs on 19-Oct-2003 12:02 GMT
In reply to Comment 22 (Anonymous):
I don't really care if its V943.6, V1.5 or V1.4 of MorphOS with Pegasos2, all I want is, is it to work with the new NB and ethernet.

I suggest you do the same.
DC Pegasos Show Mini-Report : Comment 24 of 50ANN.lu
Posted by Nate Downes on 19-Oct-2003 13:33 GMT
In reply to Comment 14 (Kronos):
Yes there is, actually. It is called CHRP. That is why it is dead-easy to port common PPC OS's to the Pegasos. Apple has a customized system design, mostly CHRP but with some superset material that only Mac OS/X uses to prevent someone from running it on non-Apple hardware so I understand. (as shown by when someone compiled Darwin on a Mac and it still could not run Mac OS X, these proprietory bits that bang the dongle are Apple's key strategy to control the system)
DC Pegasos Show Mini-Report : Comment 25 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 14:36 GMT
In reply to Comment 18 (Don Cox):
Don Cox said,

> This is because Microsoft (and the Linux community) don't write the
> BIOS. The Genesi people write their own BIOS, so they can do all the
> setup there, where it should be done.

Hmm. I don't know a heck of a lot myself, but 'doing it right' with OF might be a little difficult.

You can embed drivers in OF, beyond whatever setup is done by the initial hardware bootstrap from the ROM/available through the standard OF features, but that's some form of "native" code that the OS has to deal with, right? And MOS in particular may be a shifting target in that regard, while, as noted in the NetBSD thread that became a ramble on U-Boot, the 'postmodern' approach (pushing as much as you can out to software) seems to be the right thing to do these days no matter what platform you're on.

Now, the chipset shouldn't require ridiculous levels of support, but... as example, take a look at this chunk of code (URL split across two lines to avoid stretching everyone's display, join them, obviously):

http://cvs.sourceforge.net/viewcvs.py/amigaone-linux/
2.4.21-rc1-benh0/arch/ppc/platforms/chrp_pci.c?rev=1.1.1.1

Now, all the "Oops, OF leaves the IDE controller in the wrong state" functions are obviously things that could be fixed in OF, but notice that the kernel still needs to know these things about the PCI bridges even after OF has presumably "set up" and identified them. (Or more specifically, even a PCI bridge is just a 'peripheral' for the OS to spin up after the underlying code in OF gets you to the point where you can load and execute a kernel?)

As I understood the whole point of OF (as brought to PPC land, anyway), it's *supposed* to kind of enumerate the hardware and step aside, rather than carry on the "wastefulness" of Wintel's constant reimplementation of BIOS features no sane OS author would depend on anyway. There's (preexisting, via Sun?) feature creep -- everyone wants to be able to put up a text console without innate awareness of the hardware -- but beyond that, isn't the attraction supposed to be its "elegant simplicity?"

And the difference is that U-Boot doesn't even bother trying to enumerate you a device tree, since if you can identify or assume the *really* basic stuff, you conceivably know how to extract one in software anyway?

Sounds to me like you're asking for Kickstart, while life proves more fun if you can softkick anyway. (Having a Kickstart equivalent - firm or soft - does mean you can make more assumptions in the kernel/OS builds, and be more confident that the same distribution works across varying hardware... *but* only if all the work that would've been done 'in the OS' winds up in the Kickstart; it just pushes the problems around. If you want to do it right, may as well ROM the OS itself, and rewrite it for each hardware... Hmm, sounds something like a certain environment, one that might be digital. ;))
DC Pegasos Show Mini-Report : Comment 26 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 15:01 GMT
In reply to Comment 24 (Nate Downes):
Nate said,
> Yes there is, actually. It is called CHRP. That is why it is
> dead-easy to port common PPC OS's to the Pegasos.

On that note, I don't want anyone to take the above as knocking CHRP; it was/is a leap forward from The Days All Hardware Was Different, and puts PPC on a foundation that's as good or better than what Wintel's evolved.

But nothing's ever pixie dust, and again AFAIK, it's more about having ground rules set at all... than guaranteeing you can deploy an OS with zero chipset knowledge whatsoever...

At least, an OS with reasonable levels of performance. What exactly do the OF RTAS ("Run Time Abstraction Services") it calls for provide? (Enough for the PPC equivalent of MS-DOS?) And how many of those do you want to keep using if you know how to bang your hardware more directly?
DC Pegasos Show Mini-Report : Comment 27 of 50ANN.lu
Posted by Anonymous on 19-Oct-2003 15:31 GMT
In reply to Comment 12 (Don Cox):
You're wrong.

Yes, the firmware can pull code off a disk and begin executing it. Yes, on modern architectures this is sometimes enough to start the OS kernel (on x86 the bootloader software is pulled in, and the 2nd stage of the bootloader loads the operating system, an additional step). No, decent operating systems don't continue to use this bootstrap functionality as if it were the real thing.

You might think of a car engine for an analogy. Yes, the electric starter is capable of turning over the engine, but we burn fuel instead once the engine is going.

The Linux kernel includes lots of chipset specific code, which in a less integrated system would be in the form of special "drivers". In some cases this code is optional (it merely provides extra features or optimisations) in other cases the system will not work without the chipset specific code, or will work only in a lousy "compatability mode" e.g. single CPU, no large RAM support, etc
DC Pegasos Show Mini-Report : Comment 28 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 16:30 GMT
In reply to Comment 27 (Anonymous):
You are saying that "modern" operating systems are badly designed. I can believe this when the BIOS and the DOS come from completely different sources.

But in the case of the Pegasos and AmigaOne, the authors of the BIOS know all about the motherboard and all about the DOS (disk-based OS). So why would they set up the RAM or IDE access wrong in the BIOS and then correct it in the DOS later? The obvious correct place for all the code for hardware on the motherboard is in the ROM on the motherboard. Then when the DOS loads from disk it is in a properly set up environment - and you don't need a different version of MorphOS for PagasosI, PegasosII, PegasosIII, etc etc.

Maybe Genesi and Hyperion have made a nonsense too, but I don't see why they should.

Even on Linux, you don't need a different version for different motherboards. Stick a Knoppix CD in the drive and it boots. The ROM contains all that is needed to copy code from disk to RAM and run it.
DC Pegasos Show Mini-Report : Comment 29 of 50ANN.lu
Posted by Kronos on 19-Oct-2003 16:44 GMT
In reply to Comment 28 (Don Cox):
>Even on Linux, you don't need a different version for different motherboards.
>Stick a Knoppix CD in the drive and it boots. The ROM contains all that is
>needed to copy code from disk to RAM and run it.

And why is that ? Maybe because the "standard" kernel of most Linux-distros contains
tons of drivers for even the obscurest HW.

Try booting an old OS (Win9x, OS/2, or an old Linux) on an nForce-based mobo and
see how far you will get .... some will boot, others not, but none will be capable to get
the max power out of the HW,until you install some specific drivers (if available).
DC Pegasos Show Mini-Report : Comment 30 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 16:55 GMT
In reply to Comment 29 (Kronos):
"Try booting an old OS (Win9x, OS/2, or an old Linux) on an nForce-based mobo and
see how far you will get .... some will boot, others not, but none will be capable to get
the max power out of the HW,until you install some specific drivers (if available)."

"max power" is a vague expression. If the RAM can't be accessed properly, for example, that is a design failure. There is no reason why such a mistake should be made on a properly integrated computer from one company, such as a Mac or a Pegasos.

Obviously drivers for interchangeable components such as AGP graphics cards have to be on disk. But adding a new graphics driver is not making a new version of the OS.

On Amigas, WB 1.3 or 2 will run fine on an A4000.
DC Pegasos Show Mini-Report : Comment 31 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 17:05 GMT
In reply to Comment 28 (Don Cox):
Don, look at that link I posted, unless you know better. ;)

Even OF (which is more an abstraction than PPCBoot/U-Boot) just isn't intended to get you to the point you're asking for. (See those device-specific structures for communicating with the PCI bridges? As far as I know, that's what you get/"still have to do" when you use OF *properly.*)

Surely you're aware of how much crap Knoppix goes through to "just make it work?" And again, that's an argument for having the abstractions *out of ROM* entirely; Knoppix can update its drivers and just release a new CD to burn (versus a ROM image to burn, that will 'destroy' your machine if you screw up); a Knoppix-like solution on a CF for second-stage bootstrap could do the same thing, merging the benefits of solid-state "embeddedness" and 'soft'-ware "malleability."
DC Pegasos Show Mini-Report : Comment 32 of 50ANN.lu
Posted by Kronos on 19-Oct-2003 17:08 GMT
In reply to Comment 30 (Don Cox):
That is because the A4000 is fully backwards compatible on a HW-level (except for
nasty stuff like self-modifying code, or overwritting unused register-bit).

I also assume you mean WB1.x, ontop of Kick3.0/1,and we all should have learned that
keeping important parts of the OS in ROM is an obseleted design of the 80s.

Back to the case:
Lets assume the Marvel-NB does support PCI-DMA in a slightly different way that the
MAI-NB, for example by allowing more but smaller DMA-transfers at the same time
(I know that I'm probraly completly in th off on this, but it should be o.k. as an example).

That's something you can't fix by setting some registers, that something that has to be
intregrated (and hidden behind the HAL) into the OS.

Does that mean a "new" version of the OS,or just a new revision ?
Doesn't matter, cos it will need a different boot.img, even if just 10 lines of asm have
been changed ....
DC Pegasos Show Mini-Report : Comment 33 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 17:09 GMT
In reply to Comment 31 (Joe "Floid" Kanowitz):
Addendum to that - we (whether "red team" or "blue team") don't *want* to just run under Linux, hence my take on using it as a 'driver set' for obscure boot devices and then throwing it out the window. But the Amithlon road certainly works, and is equivalent to having a really, really powerful "Kickstart" abstraction. (The features of an entire *NIX, in fact... ;))
DC Pegasos Show Mini-Report : Comment 34 of 50ANN.lu
Posted by Don Cox on 19-Oct-2003 17:21 GMT
In reply to Comment 32 (Kronos):
"Lets assume the Marvel-NB does support PCI-DMA in a slightly different way that the
MAI-NB, for example by allowing more but smaller DMA-transfers at the same time
(I know that I'm probraly completly in th off on this, but it should be o.k. as an example).

That's something you can't fix by setting some registers, that something that has to be
intregrated (and hidden behind the HAL) into the OS."

And the part of the OS it should be in is the part in the ROM, so that it is linked to the board in question. Otherwise how could you move a disk with the DOS on it to a different board? If you update the motherboard, for instance.
DC Pegasos Show Mini-Report : Comment 35 of 50ANN.lu
Posted by Kronos on 19-Oct-2003 17:27 GMT
In reply to Comment 34 (Don Cox):
How ?
You boot from the newest CD and replace the boot-file on the HD....
Or maybe you can boot the HD directly in a fail_safe-dead_slow-no_DMA-mode.

But putting parts of an OS into is simple stupid,and just doesn't make any sense
in these days !
DC Pegasos Show Mini-Report : Comment 36 of 50ANN.lu
Posted by Joe on 19-Oct-2003 18:00 GMT
In reply to Comment 34 (Don Cox):
Don said,
> And the part of the OS it should be in is the part in the ROM,
> so that it is linked to the board in question. Otherwise how
> could you move a disk with the DOS on it to a different board?
> If you update the motherboard, for instance.

You include all five bazillion drivers monolithically, as Knoppix does. (And Windows does, to some extent, though MS 1. broke this by having a 'base set' that didn't support Via well enough out of the box in '98, and 2. stopped trying anyway, because they want you to purchase a new license each time you install hardware. Viz the move from "OEM" discs to cut-down 'recovery CDs' that only include the set for your particular Compaq/Dell/Gateway.)

Really, you get screwed either way; again see the point on 'pushing the problem around.' The advantage of the software road is that you can usually find a working box to push drivers onto your 'broken' install from, while if ROMs ever end up incompatible, it's harder (and sometimes less legal!) to track down a new ROM.

And then, since ROMs are such a pain anyway, you end up doing like Apple did (and later Amiga evolutions have done) - you take advantage of the base ROM, but end up shipping tons of patches in the OS that overlay it anyway.

It's nice to have an abstraction to fall back on, but it can't help but conflict with the desire to always have/support the latest and greatest. Is "wasting space" in ROM any more elegant than "wasting space" on disk, just because the user can do something about one but not the other?

This is a serious problem for embedded guys, but those guys are looking at the size of the image as a whole; it doesn't matter if it's in KS or 'disk,' because it's all getting blown on the same ROM anyway... If anything, what matters is how easy it is to rip out the parts they'll never have to use. (When a system is properly modular, ripping things out is easier than coding a new firmware... Most of today's OSes don't make it so easy, but QNX6/RtP/Momentics/what's_next,QNX_Anywhere? shows it needn't be painful.)

Yeah, it's annoying to make these points after years of "utmost" efficiency, but cripes, a *gigabyte* of disk is probably cheaper than a single ROM chip right now. When MRAM (or nanotube memory, or any other miracle tech) hits the scene, it's going to make a good argument for "keeping a balance," but we don't need to blow our brains out... The first chips are destined for cellphones, but even those demand more RAM than the 1000 had to work with.

http://www.theregister.co.uk/content/archive/31117.html
Already halfway to that point... and hm, IBM makes a line of chips known to benefit from large, fast caches...
DC Pegasos Show Mini-Report : Comment 37 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 18:10 GMT
In reply to Comment 36 (Joe):
My bad. That link suggests kilo*bits.*

1/16th of the way there, but Moore's on our side as much as Wintel's. The question is whether the orders of magnitude (even a "bloated" solution from this scene is 1/16th of MS desktop requirements) will be enough to overcome the usual delays in hardware availability/production.
DC Pegasos Show Mini-Report : Comment 38 of 50ANN.lu
Posted by BrianK on 19-Oct-2003 20:03 GMT
In reply to Comment 26 (Joe "Floid" Kanowitz):
But nothing's ever pixie dust?

Really IBM put 'Pixie Dust' in their harddrives before the sale of their hard drives to Hitachi.
DC Pegasos Show Mini-Report : Comment 39 of 50ANN.lu
Posted by BrianK on 19-Oct-2003 20:08 GMT
In reply to Comment 28 (Don Cox):
Even on Linux, you don't need a different version for different motherboards..

That's not true. Linux has specific drivers built into it's kernel for the different chipsets. After inital load you can remove the pieces you don't need (if you're using VIA remove all the nforce stuff) and recompile the kernel.
DC Pegasos Show Mini-Report : Comment 40 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 19-Oct-2003 21:25 GMT
In reply to Comment 38 (BrianK):
BrianK said,
> Really IBM put 'Pixie Dust' in their harddrives before the sale of
> their hard drives to Hitachi.

Yes, and we all know what happened there.

(Likely 110% unrelated, of course.)
DC Pegasos Show Mini-Report : Comment 41 of 50ANN.lu
Posted by Anonymous on 20-Oct-2003 10:41 GMT
In reply to Comment 2 (Joe "Floid" Kanowitz):
The Pegasos/AmigaONE hardware should be more than enough to encode MPEG1 (video and audio) streams in realtime (VHS quality).

MPEG2 is NOT going to happen without some hardware doing the hard work. (On my dual AMD 1.8GHz it takes 5 hours to encode 1 hour, using TMPGEnc). But there are plenty of USB and PCI cards that happily would do the encoding on-the-fly.

Now, this is a sellingpoint!!! Why use big PC-machines as PVR, when you can get a "VCR-sized" Pegasos doing the job instead?

Come on now Genesi... make it happen... make the Pegasos utilize those USB and PCI cards... Make Pegasos do what PC:s have been doing for a couple of years! ;)
DC Pegasos Show Mini-Report : Comment 42 of 50ANN.lu
Posted by alan buxey on 20-Oct-2003 11:03 GMT
In reply to Comment 6 (Don Cox):
as the new upgrade is free (unlike the farcical >$100 for MacOSX 10.3 !!!)
I wouldnt worry.

we've alsways had new OS releases in the Amiga world for new Amiga hardware.

why change a habit of a lifetime? :-)

alan
DC Pegasos Show Mini-Report : Comment 43 of 50ANN.lu
Posted by BrianK on 20-Oct-2003 11:26 GMT
In reply to Comment 41 (Anonymous):
'Why use big PC-machines as PVR, when you can get a "VCR-sized" Pegasos doing the job instead?'

I agree with you I'd not use a big PC Machine. But, instead use a smaller footprint PC or one designed for the PVR purpose. There are quite a few cases that are Audio Equipment sized for this purpose. Also, many PC manufactures make small footprint PC's meant to be part of your Audio/Video setup. So, no need to use a big PC-machine but PegasOS isn't the only choice.
DC Pegasos Show Mini-Report : Comment 44 of 50ANN.lu
Posted by Anonymous on 20-Oct-2003 11:42 GMT
In reply to Comment 42 (alan buxey):
"as the new upgrade is free (unlike the farcical >$100 for MacOSX 10.3 !!!)
I wouldnt worry."

Does the upgrade offer the kind of increased cunctionality which MacOSX 10.2 -> 10.3 offers?

No?

Thought not.
DC Pegasos Show Mini-Report : Comment 45 of 50ANN.lu
Posted by Joe "Floid" Kanowitz on 20-Oct-2003 17:00 GMT
In reply to Comment 43 (BrianK):
BrianK said,

> I agree with you I'd not use a big PC Machine. But, instead use a
> smaller footprint PC or one designed for the PVR purpose. There
> are quite a few cases that are Audio Equipment sized for this
> purpose.

The existing Via chips have proved (pun just sort of happened) "not so hot" for video encoding:

http://slashdot.org/comments.pl?sid=60857&cid=5741328

That Nehemiah core was supposed to improve matters, but I'm not sure how much it really did. The new chips seem focused more towards the microserver/palmtop/dirt-cheap laptop market.

Transmeta's new baby probably has the "grunt," but that'll probably hide in laptops and blades for a while, unless you're buying a complete embedded device designed around it. (As in, "commodity" TMTA boards don't seem to exist for the consumer just yet; maybe they'll end up competing in the ITX space eventually.)

> Also, many PC manufactures make small footprint PC's meant to be
> part of your Audio/Video setup. So, no need to use a big PC-machine
> but PegasOS isn't the only choice.

Yep, a regular Duron or the latest $50 AXP can probably pull it off entirely in software (I'd include P4, but according to Pricewatch, there's no such thing as a $50 P4!). The power consumption won't really kill you, but the noise from the fans (and associated ventilation requirements) might, so there's always room for something better.
DC Pegasos Show Mini-Report : Comment 46 of 50ANN.lu
Posted by BrianK on 20-Oct-2003 18:09 GMT
In reply to Comment 45 (Joe "Floid" Kanowitz):
Anyone know if ATI's All-in-Wonder cards for AmigaOS4 or MorphOS are planned? They'd be a nice addition for Mpeg2 and Mpeg4 capture.
DC Pegasos Show Mini-Report : Comment 47 of 50ANN.lu
Posted by strobe on 21-Oct-2003 05:10 GMT
In reply to Comment 41 (Anonymous):
That's pretty pathetic. Apple's MPEG2 encoder on a Ghz G4 will encode 2 hours of video in an hour (and it's high quality encoding).

Still not real time, but your encoder is still pathetic.
DC Pegasos Show Mini-Report : Comment 48 of 50ANN.lu
Posted by alan buxey on 21-Oct-2003 08:37 GMT
>We all need to send the Mplayer programmers


the programmers dont want money.

<a href="http://mp.dev.hu/homepage/design6/donations.html">

http://mp.dev.hu/homepage/design6/donations.html</a>

..or do you give money to the people who ported it to MorphOS?

Alan
DC Pegasos Show Mini-Report : Comment 49 of 50ANN.lu
Posted by MIKE on 21-Oct-2003 14:21 GMT
In reply to Comment 46 (BrianK):
Well, the support is really not that good under linux, I have some all in wonder Radeons, have to use some third party drivers (Gatos Project), that ATI won't support, tuner works, out-to-TV works, haven't got capture working properly, but it's all hackish, and quite a pain.
DC Pegasos Show Mini-Report : Comment 50 of 50ANN.lu
Posted by Anonymous on 21-Oct-2003 21:07 GMT
In reply to Comment 47 (strobe):
>Apple's MPEG2 encoder on a Ghz G4 will encode 2 hours of video in an hour (and it's high quality encoding).

"And it's high quality encoding" isn't exactly a precise qualifier ;-) The time drastically depends on size, frame rate, quality and the audio format, not to speak of supportive hardware. Don't even think of making comparisons if you don't know the parameters. That said, for video encoding, a G4 (with Altivec) at 500 MHz is roughly equivalent to an Athlon 700 mmx/sse. The G4 is faster on a per MHz basis but it is not a wonder-with-mouth-open difference. Here are some charts: http://klicman.org/altivec/
Anonymous, there are 50 items in your selection
Back to Top