Nulldce On The Beagleboard


Actually since all my PC's were overclocked (since I386SX 33@40mhz) I dont have a problem with that. And about short lifespan. My friend still owns my old Celeron 600 @ 900 wich is nearly 9 y.o. and still operates perfectly. Most electronics die because of temerature, not the fact of overclocking. And BTW newest GPU's consider 90-100*C as a normal operating temperature. My old 8800GTS would shut itself down at 115*C.. So I dont see a problem with Pandora at all!

And at behalf of mobile chips. They fail long before ANY damage could be done at all. For example I was overclocking my old cell phone xD Some Qtec of sort with 200mhz omap up to 300 just to be able to use High quality stereo bluetooth so MP3's would sound somewhat good xD And it was getting abit warm, that all. And it wont fail on you. You break the thing long before something can happen to the CPU.

So stop this OC worries. Time's when old athlons failed with fire-show without heatsinks long gone.
 
Last edited by a moderator:
'God Ginrai' said:
if you reduce the lifetime, you're damaging it. Also, Squidge said 900 MHz would be fine.
i haven't read what squidge has said, but i know what the OMAP specs say:

putting the main DPPL into overclock mode _does_ decrease the lifespan, up to 50% from memory.

there are not ifs, buts and maybes.
 
Last edited by a moderator:
'Exophase' said:
That's almost always the case with these clocks. Yes, of course the caches are running at the CPU clock, since they're internal to the CPU.

That's a pretty arbirarty thing to say, other OMAP chips are rated at speeds of 800MHz or more and ARM says the chip design is capable of > 1GHz. It's not magic at all.

Rarely is a CPU permanently damaged by overclocking (beyond decreasing the lifespan, but usually the lifespan is much longer than what people use it for). Usually it fails to operate (and requires rebooting) long before it overheats to the point where something bad happens. And chips can often operate at temperatures well in excess of 50C, some even beyond 90C.
It's not that unusual for the cache to run on a different clock than the cpu itself (the L2 cache, not L1).I must say i have never used overclocking on a protable device, but on pc the memory clock is indepedant.Other OMAP chips are higher spec'd, but as far as they know they use a different manufacting process.Our chips aren't :p.I had many cpus die due to heating problems (especially on work-pcs, they never clean the damn hsf ever).The design may be capable of super speeds but that dones't mean that the implementation can actually reach em.After all, if it was that safe to use the higher clocks it'd be within spec and without the notice that 600 mhz can reduce the lifetime of the parts.While the typical (calculated by promotion staff and not really tested) lifetime may be long, many failures happen before it and overclocking is just gona that worse.

I'm not saying that pandora can't be overclocked, or that some pandoras may run for years and years at 900 mhz and never have a problem.I'm saying that not *all* will.And i'm not gona risk mine, nor i think that other people should.

It never hurts to be pleasantly suprised by the final hardware, but if i ever see a post like "I overclocked my pandora to play with nullDC and its now dead" i'm gona feel really bad :|

(So yeah, i generaly don't overclock any of my hardware :p)
 
Last edited by a moderator:
The Pandora could run for 5 years constant time if clocked at 900Mhz rather than something like two or four times more at it's default clock. I remember this was what was mentioned many months ago and there was some sort of specification sheet rolling about that backed this up.

I mean no offence to you but this is a portable implementation with a completely different design to any X86 CPU. You can not treat it identically to your broken PCs. Which must all be over 10 years old because as far as I know all modern set-ups stall the CPU and/or turn off when a threshold temperature is reached. Oh, that and 50 degrees is nothing as my laptop is running 24/7 and is currently rolling at about 70 degrees.

Edit: Just for the record as far as I remember no one ever broke a GP2x or a GP32 even by over clocking without changing the vcore.
 
Last edited by a moderator:
also... even with the overclock it isn't getting hot... the only reason your gonna have a fail is that the logic on the chip just can't keep up iirc the overvoltage for 900mhz is still within spec with accepable reduction in lifetime

also don't forget the CPU halts when idle .... so the actual CPU lifetime will never be equal to real time so even with an overclock it'll probaby run at least 10 years assuming 50% load (and none of my Linux Boxes even come close to that more like .2 load)
 
Last edited by a moderator:
I know I'm new here, but could we get back to talking about DC emulation and how fantastic it would be?
 
Last edited by a moderator:
It needs a vcore bump to get to 600 mhz, from 500.I don't think you'l get it at 900 without changning vcore.

Oh, and how are your 5 year old pandoras btw? Did you build a time machine and went back 5 years and now you can report they work :blink:.All these figures are based on speculation, mostly-pr-provided figures and guesswork (i don't know any product that uses a chip of the same family that is released for the general public yet).As far as i remember GP2x and GP32 didn't a Cortex A8 SoC :p.

Cpu designs aren't that much different.Yeah, its a different architecture, with different encoding etc etc etc .. but as the cpu starts to get more complex the decoder frontend becomes a tiny part of the transistor count (especially if you look at the massive space caches take ...).The real win over x86 is that its a system on a chip -- all these extra chips and things you need for x86 eat a lot of power :).After all the atom alone has similar power profile (<1W for low power versions) but the supporting chips are 15W+.

And thats the last post i'm gona make on this subject.The point is to get this to run on the pandora, and we don't even have the hardware yet.After it runs we'l see how overclocks helps the speed and if it hurts the hardware ;p.
 
Last edited by a moderator:
'drkIIRaziel' said:
Beagle gets at 50 degC w/o a hsf at 500 mhz, doesn't it ? (i think i recall the value from some youtube presentation) Thats cool, but close to bad temperatures for overclocking if no hsf is used.

There may actually be something wrong with your board. Squidge did a temp test a while back on his omap dev board and the chip stayed under 35C, even after two hours runing at 925MHz.
 
Last edited by a moderator:
no ARM designs are significantly different..... as far as i know arm uses hardwrired logic.. whereas x86 uses microcode leading to huge power usage and # of transistor differences for instance the current smallest arm cpu is only 12k transistors the cortex M0 running at 50mhz an only haveing the thumb instruction set iirc

just because a chip does similar things doesn't mean the are the same in implementation which they clearly arn't the same implementation weird your beagleboard getting hot like that I don't think my sempron even gets that hot

FYI the atom can be a SoC as well....
 
Last edited by a moderator:
'Chip' said:
'drkIIRaziel' said:
Beagle gets at 50 degC w/o a hsf at 500 mhz, doesn't it ? (i think i recall the value from some youtube presentation) Thats cool, but close to bad temperatures for overclocking if no hsf is used.

There may actually be something wrong with your board. Squidge did a temp test a while back on his omap dev board and the chip stayed under 35C, even after two hours runing at 925MHz.
I don't have a beagleboard -- i was quoting numbers from the youtube videos of it :D (the official ones).You guys know any places to get one from within Europe ?

Simple decoding logic is has a huge benefit as long as you don't have an out of order/super scalar design cb88.12k for a (thumb only) arm cpu is impressive but nowhere near useful for our purposes.Atom SoCs aren't out yet -)
 
Last edited by a moderator:
drkIIRaziel is expected to use DSP of the OMAP to decode sound or other dreamcast hardware?
the SGX on OMAP is more recent then the one in dreamcast, no? it may be more power if newer?
 
... wow, way too many posts for me to comment on or reply to them all.

Glad to see people interested in the project..

Some replies/info/details:

I do not have a pandora unfortunately, doesn't even look like I can get one?
If anyone can help me out here that would be nice :) ..

The beagle i'm testing on is a RevB5, I am using a newer 2.6.28 kernel, and most specifically i'm NOT running X at all. The emulator should run on the pandora, but until I own one there won't be any specialized builds for it as i can't test it. You will need a few packages installed: Probably DirectFB / SDL on DirectFB, obviously the PowerVR drivers of a similar revision.

We will make the best use of the hardware possible, not sure about DSP yet. I've started some testing on it, but audio wont be implemented until optmization has been completed. If its not fast enough to run the game fullspeed, audio will just slow it further and sound like sh1t too...

The powervr chipsets are indeed very different, but as far as this one being much more powerfull, there are other things to look at. The dreamcast clx2 chipset had a reasonable amount of vram on a 64b bus where textures and geometry were cached, two accumulation buffers, and a true hardware bumpmapping format among other features.

I dont how low level documentation of the sgx chipset, and i have to use OpenGL ES unless i have documentation for libpvr. Which means some nasty things like textures must be converted from their native format (that sgx can likely handle!) and then loaded in gl es, which in turn converts them back again and saves a cache of them in local memory.

I expect some reasonable performance out of the omap3, and the rate its going it might even happen sometime soon :). However do not expect a release right away, I wont be releasing it until there are games fully playable. If/when I have a pandora, I may need some beta testers but with the complete lack of available hardware, that may be quite a while.

The emudev.org/nulldc_beagle site was a temporary thing.
I will be using the front page of emudev.org eventually, so look there for updates.

Thanks for the support !
 
Last edited by a moderator:
I've been playing games for quite a long time. Starting with Atari 2600/Colecovision. None of the systems have wowed me in the way that Sega's swansong, the Dreamcast, did. Needless to say this project excites me greatly. Thank you for the work and I wish you good luck with future progress!
 
Last edited by a moderator:
Zezu maybe you should try to contact maciek_ubanski (from this forum) I think he is doing some reverse engineering on the sgx, I have no clue about what he knows but you can always ask, it might be usefull.
 
'ZeZu' said:
I dont how low level documentation of the sgx chipset, and i have to use OpenGL ES unless i have documentation for libpvr. Which means some nasty things like textures must be converted from their native format (that sgx can likely handle!) and then loaded in gl es, which in turn converts them back again and saves a cache of them in local memory.

indeed, the clx2 and the sgx support the same family of texture compressions (pvrtc) but i am not aware how similar the actual encodings used in the two architectures are. in the best-case scenario sgx should be able to use clx2 textures with little-to-no touching. hmm, that is worth checking..
 
Last edited by a moderator:
Actually, according to pvr docs the compressions used are totally different.Dreamcast uses a simple 256 2x2 pixel palette that is very simple to downsample to a normal paletted texture (thats what i do on psp).
 
God Ginrai said:
ARM processors are very resilient. They don't damage that easily, if at all from overclocking, unlike x86. I overclock my GP2X all the time for emulation, and its ARM processor hasn't shown any sign of damage.
In the case of your GP2X, it's a differing class of ARM. Overclocking the Cortex-A8 will cause a bit of electromigration and an increase in heat- much more than the case you use. It'll shorten the life of the device by quite a bit. And, until you KNOW you need it, why presume you do?


God Ginrai said:
I think that overclocking from 600 MHz to 900 MHz should make a little bit bigger of a difference than 4 fps. Also, I have to humbly disagree with you on your views that it will damage the ARM, based on my experiences with OCing my GP2x, and a plethora of posts by devs that I know and trust a lot more than you (not that you're not trustworthy, I don't know you) that say that OCing won't hurt the processor.
Please, quit using your GP2X as a guide to what you can/can't do overclocking-wise on the Pandora. They're completely differing devices. MWeston has already indicated that it's not a good idea to attempt this stuff. The engineering samples can overclock to 900MHz, but there's NO assurances that the production parts will 100% consistently and stably do the same thing as they're not paying TI to speed rate the parts to be overclockable- which costs quite a bit more money.

Also worth noting, you're only overclocking to half-again faster speeds with this if it DOES work on your unit. IF you're seeing only 8fps, for example, the best you'll get is another 4 (which is more likely to be 2-3- not everything gains a 1:1 ratio increase when you overclock...). Again...unless you know you need to overclock why do it? Moreover, why even go and produce something other than a POC that would need OC in the first place?


Peter R said:
The Pandora could run for 5 years constant time if clocked at 900Mhz rather than something like two or four times more at it's default clock. I remember this was what was mentioned many months ago and there was some sort of specification sheet rolling about that backed this up.
Please don't state this as a fact. TI's spec sheets do not indicate this and our Hardware Dev for the project indicates that what we're getting may/may not do what the dev boards have shown to be able to do in that area.

QUOTE

I mean no offence to you but this is a portable implementation with a completely different design to any X86 CPU. You can not treat it identically to your broken PCs. Which must all be over 10 years old because as far as I know all modern set-ups stall the CPU and/or turn off when a threshold temperature is reached. Oh, that and 50 degrees is nothing as my laptop is running 24/7 and is currently rolling at about 70 degrees.



And you can't presume that just because it's a mobile device you can do overclock games on it. Most mobile devices actually don't do well at this sort of game. Seriously. I've worked in this and other similar spaces for some time now. Operating out of spec may work- but it doesn't mean it's stable (If I hear you're operating one of the titles I produce in that mode I'll tell you to take it out of it first before reporting an issue...moreover, you'd better be honest about the overclock mode... ;)) and it doesn't mean that all mobile devices of that same class will DO that unless the vendor spec'd parts that could let you play that game.

MWeston has already indicated that while the mode's going to be there, we shouldn't go and presume that it'll work with all units and we shouldn't be coding titles, etc. to need that mode unless absolutely needed.

QUOTE

Edit: Just for the record as far as I remember no one ever broke a GP2x or a GP32 even by over clocking without changing the vcore.


Please...do NOT use the previous devices as a metric for this subject. What one could/could not do with the old parts does NOT equate to the Pandora. Seriously.
 
Last edited by a moderator:
Svartalf said:
Peter R said:
The Pandora could run for 5 years constant time if clocked at 900Mhz rather than something like two or four times more at it's default clock. I remember this was what was mentioned many months ago and there was some sort of specification sheet rolling about that backed this up.
Please don't state this as a fact. TI's spec sheets do not indicate this and our Hardware Dev for the project indicates that what we're getting may/may not do what the dev boards have shown to be able to do in that area.I'm pretty sure it does, more or less. Read back to the threads which I posted. I don't fully understand the terminology used, but the translation into lay-speak was that the modifications needed to overclock to 900Mhz left it rated for 44K hours of use. In simple, easy to understand terms, that's 5 years of continuous, 24/7 use. That 44K number may just be an extrapolation, but it's still based in scientific figures and calculations that would not be unreasonable to trust.
 
Last edited by a moderator:
Back
Top