128mb Of Ram...


jdh2550 said:
We saw some wild demos this week running all kinds of software and not one of the kits had more than 128MB. Honestly, when we preview Pandora running real apps soon (not committing to any dates with this email, I just got home!) you will be blown away. This chip is unlike anything anyone has ever seen. It truly is a PC grade chip with an ARM core. If the dev kit was hidden behind the monitor, you would swear it was just your PC running a variation of some linux desktop complete with an amazingly full speed Firefox browser. There was no lag or scroll issues whatsoever, even at 720p.
2301322446_8335181411_o.png
 
Last edited by a moderator:
atomicthumbs said:
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:


:gp2x :eek: :ph34r:

:lol: :lol: :lol: :lol:


That is brilliant AT :).

I suspected as much (IE that a "more ram" unit might possibly turn up), but I don't think it would be good if it came in the next couple of years, because in the time while we have the 128 model all the software will get a good and thorough tweaking (Not to mention that with the way Zodttd has tweaked the ARM PSX emu it will be fullspeed without hardly any work!!!).

I was thrilled to hear of "720p" models running a desktop ;), I am still thinking that we will see a VGA/HDTV version of this before we will see a 256MB model (at least I think user demand for the HD model will be higher than for the larger memory model). Not that it needs either, at least not for a year or two.

Yay, I want to learn more about what happened at TIDC, off to scour the forum.
 
Last edited by a moderator:
nubie said:
:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
:gp2x :eek: :ph34r:

:lol: :lol: :lol: :lol:


That is brilliant AT :).

-snip-

Yay, I want to learn more about what happened at TIDC, off to scour the forum.



The Reaction Guys are always a sure win.

Also, don't bother scouring the forums; I already have. There won't be much until Monday, most likely.
 
Last edited by a moderator:
jdh2550 said:
...
I have my answer from the horse's mouth. I'll stop posting - unless others keep posting telling me how much ram such and such an OS uses or how much ram it takes to convert any particular game. Deal?
Thanks for asking. This is the most interesting post for a long time. ...do not stop posting - if you own informations like this! Deal? :lol:



jdh2550 said:
...
I'm definitely buying one of the first ones I can lay my hands on - even if you cut the memory in half ;-) - and I don't blame you for not committing to dates!
...
I intend to do just that. ;)
 
Last edited by a moderator:
Exophase said:
Of all the handhelds/SoCs that I've heard of that use PowerVR accelerators, Dell's Axim x50v+ is the only one I know of that has dedicated VRAM (in this case the 2700G came with a relatively massive 16MB). It'd be nice to have dedicated VRAM (so the 3D card can work w/o slowing down the main bus), although L2 cache alleviates this somewhat. It'd be even better to have the best of both worlds and have VRAM that's on a relatively fast path to the CPU, at least for writing.
I didn't know that there existed designs where the FB was not dedicated VRAM.
Anyway just found this: TI.
Doesn't say much but it's some "official" info at least :)
 
Last edited by a moderator:
Laurent said:
Exophase said:
Of all the handhelds/SoCs that I've heard of that use PowerVR accelerators, Dell's Axim x50v+ is the only one I know of that has dedicated VRAM (in this case the 2700G came with a relatively massive 16MB). It'd be nice to have dedicated VRAM (so the 3D card can work w/o slowing down the main bus), although L2 cache alleviates this somewhat. It'd be even better to have the best of both worlds and have VRAM that's on a relatively fast path to the CPU, at least for writing.
I didn't know that there existed designs where the FB was not dedicated VRAM.
Anyway just found this: TI.
Doesn't say much but it's some "official" info at least :)


I think it's pretty common. A lot of platforms have unified memory, especially consoles (N64 and the original XBox come to mind). Even GP2X doesn't have dedicated framebuffer space, just uses parts of SDRAM (I think it's limited to the upper region though).
 
Last edited by a moderator:
Exophase said:
Laurent said:
Exophase said:
Of all the handhelds/SoCs that I've heard of that use PowerVR accelerators, Dell's Axim x50v+ is the only one I know of that has dedicated VRAM (in this case the 2700G came with a relatively massive 16MB). It'd be nice to have dedicated VRAM (so the 3D card can work w/o slowing down the main bus), although L2 cache alleviates this somewhat. It'd be even better to have the best of both worlds and have VRAM that's on a relatively fast path to the CPU, at least for writing.
I didn't know that there existed designs where the FB was not dedicated VRAM.
Anyway just found this: TI.
Doesn't say much but it's some "official" info at least :)


I think it's pretty common. A lot of platforms have unified memory, especially consoles (N64 and the original XBox come to mind). Even GP2X doesn't have dedicated framebuffer space, just uses parts of SDRAM (I think it's limited to the upper region though).


I believe that the Xbox 360 also has a unified architecture :) (although the gpu seems to have seperate framebuffer eDRAM which I guess was the initial point :p)
 
Last edited by a moderator:
Exophase said:
I think it's pretty common. A lot of platforms have unified memory, especially consoles (N64 and the original XBox come to mind). Even GP2X doesn't have dedicated framebuffer space, just uses parts of SDRAM (I think it's limited to the upper region though).
Indeed, but then you pay a performance price because you share the bandwidth, and the FB refresh always has priority. This was the case for the Amiga and the Atari ST and for the Xbox which was criticized for this by some developers.

Oh well, only having the beast will show us the truth :D

By the way, I am quite surprised by what MWeston said: I could not find the Omap3430 datasheet.
 
Last edited by a moderator:
jdh2550 said:
It truly is a PC grade chip with an ARM core. If the dev kit was hidden behind the monitor, you would swear it was just your PC running a variation of some linux desktop complete with an amazingly full speed Firefox browser. There was no lag or scroll issues whatsoever, even at 720p. Again, I point out only 128MB
Wow. :blink:
I can't wait for the TI media! Argh!

*drops dead*
 
Last edited by a moderator:
Hopefully this will mean that there will be a huge flock of developers to the platform once it is released. I'd buy one if I'd never heard about the GP32/GP2X and saw the specs...
 
Laurent said:
Exophase said:
I think it's pretty common. A lot of platforms have unified memory, especially consoles (N64 and the original XBox come to mind). Even GP2X doesn't have dedicated framebuffer space, just uses parts of SDRAM (I think it's limited to the upper region though).
Indeed, but then you pay a performance price because you share the bandwidth, and the FB refresh always has priority. This was the case for the Amiga and the Atari ST and for the Xbox which was criticized for this by some developers.

Oh well, only having the beast will show us the truth :D

By the way, I am quite surprised by what MWeston said: I could not find the Omap3430 datasheet.


We are using the 3530. That is the part number we have had in our system since November of last year, it just wasn't public so we had to keep calling it 3430. As far as I know, it's just a different number for use by different customers and the 3530 is just as powerful. The 35xx series has many different versions to strip out features that you don't need to save money, but right now we are using the one with everything.

http://focus.ti.com/general/docs/genconten...contentId=36915


To others: the frame buffer is in external RAM. There isn't enough on chip memory to do it that way. Even at 720p, there was no screen tearing on the demos I saw but of course it is possible to push the limits at some point. I just wonder what it takes to get to that limit! :)
 
Last edited by a moderator:
Whoa. Reading that link, it says that there is support for "OpenGLES 1.1 and 2.0, OpenVG1.0 and Direct3D Mobile".

Direct3D Mobile?
 
MWeston said:
We are using the 3530. That is the part number we have had in our system since November of last year, it just wasn't public so we had to keep calling it 3430. As far as I know, it's just a different number for use by different customers and the 3530 is just as powerful. The 35xx series has many different versions to strip out features that you don't need to save money, but right now we are using the one with everything.
Great news, because the OMAP3530 is actually better than the OMAP3430. It's equal to the OMAP3440 which features HD video (720p) support:

"At the high end, the OMAP35xx line closely resembles TI's OMAP34xx offerings for mobile phones, but with a larger ball-pitch and lower-volume pricing, for use in embedded applications and less mainstream consumer electronics devices.

According to Gerard Andrews, TI's OMAP marketing manager, the OMAP35x chips with on-chip graphics and DSPs will be "architecturally the same" as the Cortex-A8-based OMAP3440, which was announced earlier this month. Whereas the 34xx will be marketed only to large cell-phone manufacturers, said Andrews, TI is actively promoting the 35xx for a diverse range of applications including portable navigation devices, Internet appliances, portable media players (PMPs), and personal medical and fitness equipment.

Andrews added, "To take this technology to the broader market we needed to repackage the device with a larger ball pitch. The standard in cell phones is 0.4mm, but we're making the 35xx with a 0.65mm ball pitch.

OMAP3530 -- This superset device includes both the 3525's DSP/video accelerator capability and the 3515's graphics engine. This HD-ready chip is designed for low-power, high-performance video and gaming applications. "For a portable media player, you could use either the 3525 or 3530, depending on how aggressive you wanted to get on the UI," said Andrews. "If you wanted to go one up on the iPhone, you could go with the 3530 and bring in the 3D graphics."


Source: http://www.linuxdevices.com/news/NS5754452968.html
The article even mentions the Pandora, but of course they still think it's going to use the OMAP3430.
 
Last edited by a moderator:
MWeston said:
Laurent said:
Exophase said:
I think it's pretty common. A lot of platforms have unified memory, especially consoles (N64 and the original XBox come to mind). Even GP2X doesn't have dedicated framebuffer space, just uses parts of SDRAM (I think it's limited to the upper region though).
Indeed, but then you pay a performance price because you share the bandwidth, and the FB refresh always has priority. This was the case for the Amiga and the Atari ST and for the Xbox which was criticized for this by some developers.

Oh well, only having the beast will show us the truth :D

By the way, I am quite surprised by what MWeston said: I could not find the Omap3430 datasheet.


We are using the 3530. That is the part number we have had in our system since November of last year, it just wasn't public so we had to keep calling it 3430. As far as I know, it's just a different number for use by different customers and the 3530 is just as powerful. The 35xx series has many different versions to strip out features that you don't need to save money, but right now we are using the one with everything.

http://focus.ti.com/general/docs/genconten...contentId=36915


To others: the frame buffer is in external RAM. There isn't enough on chip memory to do it that way. Even at 720p, there was no screen tearing on the demos I saw but of course it is possible to push the limits at some point. I just wonder what it takes to get to that limit! :)



i cant say any thing but great news ;)

some info on the 3530

OMAP3530
CPU 1 64x+,ARM Cortex-A8
Peak MMACS 3440
RISC Frequency(MHz) 600
Frequency(MHz) 430
On-Chip L1/SRAM 112 KB (DSP),32 KB (ARM Cortex-A8)
RAM 64 KB
On-Chip L2/SRAM 96 KB (DSP),256 KB (ARM Cortex-A8)
ROM 16 KB (DSP),32 KB (ARM Cortex-A8)
EMIF 1 32-Bit SDRC,1 16-Bit GPMC
External Memory Type Supported LPDDR,NOR Flash,NAND flash,OneNAND,Asynch SRAM
DMA 64-Ch EDMA,32-Bit Channel SDMA
Video Port (Configurable) 1 Dedicated Output,1 Dedicated Input
Graphics Accelerator 1
MMC/SD 3
McBSP 5
Pin/Package 423FCBGA,515FCBGA
POP Interface Yes (CBB)
I2C 3
McSPI 4
HDQ/1-Wire 1
UART 3
USB 1 USB 2.0 HS 3-Port,1 USB 2.0 HS OTG
Timers 12 32-Bit GP,2 32-Bit WD
Core Supply (Volts) 0.8 V to 1.8 V
IO Supply (Volts) 1.8 V,3.3 V
Operating Temperature Range (°C) 0 to 90

edit for some more info

Features

* OMAP3530/25 Applications Processor:
o OMAP™ 3 Architecture
o MPU Subsystem
+ 600-MHz ARM Cortex™-A8 Core
+ NEON™ SIMD Coprocessor
o High Performance Image, Video, Audio (IVA2.2™) Accelerator Subsystem
+ 430-MHz TMS320C64x+™ DSP Core
+ Enhanced Direct Memory Access (EDMA) Controller (128 Independent Channels)
+ Video Hardware Accelerators
o 2D/3D Graphics Accelerator (OMAP3530 Device Only)
+ Tile Based Architecture delivering 10 MPoly/sec
+ Universal Scalable Shader Engine: Multi-threaded Engine Incorporating Pixel and Vertex Shader Functionality
+ Industry Standard API Support: OpenGLES 1.1 and 2.0, OpenVG1.0 and Direct3D Mobile
+ Fine Grained Task Switching, Load Balancing, and Power Management
+ Programmable High Quality Image Anti-Aliasing
o Fully Software-Compatible With ARM9™
* Advanced Very-Long-Instruction-Word (VLIW) TMS320C64x+™ DSP Core
o Eight Highly Independent Functional Units
+ Six ALUs (32-/40-Bit), Each Supports Single 32-Bit, Dual 16-Bit, or Quad 8-Bit Arithmetic per Clock Cycle
+ Two Multipliers Support Four 16 x 16-Bit Multiplies (32-Bit Results) per Clock Cycle or Eight 8 x 8-Bit Multiplies (16-Bit Results) per Clock Cycle
o Load-Store Architecture With Non-Aligned Support
o 64 32-Bit General-Purpose Registers
o Instruction Packing Reduces Code Size
o All Instructions Conditional
o Additional C64x+™ Enhancements
+ Protected Mode Operation
+ Exceptions Support for Error Detection and Program Redirection
+ Hardware Support for Modulo Loop Operation
* C64x+ L1/L2 Memory Architecture
o 32K-Byte L1P Program RAM/Cache (Direct Mapped)
o 80K-Byte L1D Data RAM/Cache (2-Way Set-Associative)
o 64K-Byte L2 Unified Mapped RAM/Cache (4-Way Set-Associative)
o 32K-Byte L2 Shared SRAM and 16K-Byte L2 ROM
* C64x+ Instruction Set Features
o Byte-Addressable (8-/16-/32-/64-Bit Data)
o 8-Bit Overflow Protection
o Bit-Field Extract, Set, Clear
o Normalization, Saturation. Bit-Counting
o Compact 16-Bit Instructions
o Additional Instructions to Support Complex Multiplies
* ARM Cortex™-A8 Core
o ARMv7 Architecture
+ Trust Zone®
+ Thumb®-2
+ MMU Enhancements
o In-Order, Dual-Issue, Superscalar Microprocessor Core
o NEON™ Multimedia Architecture
o Over 2x Performance of ARMv6 SIMD
o Supports Both Integer and Floating Point SIMD
o Jazelle® RCT Execution Environment Architecture
o Dynamic Branch Prediction with Branch Target Address Cache, Global History Buffer, and 8-Entry Return Stack
o Embedded Trace Macrocell (ETM) Support for Non-Invasive Debug
* ARM Cortex™-A8 Memory Architecture:
o 16K-Byte Instruction Cache (4-Way Set-Associative)
o 16K-Byte Data Cache (4-Way Set-Associative)
o 256K-Byte L2 Cache
* Endianess: ARM Big Endian, DSP Little Endian
* External Memory Interfaces:
o SDRAM Controller (SDRC)
+ 16, 32-bit Memory Controller With 2G-Byte Total Address Space
+ Interfaces to Low-Power Double Data Rate (LPDDR) SDRAM
+ SDRAM Memory Scheduler (SMS) and Rotation Engine
o General Purpose Memory Controller (GPMC)
+ 16-bit Wide Multiplexed Address/Data Bus
+ Up to 8 Chip Select Pins With 129M-Byte Address Space per Chip Select Pin
+ Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming Code Calculation), SRAM and Pseudo-SRAM
+ Flexible Asynchronous Protocol Control for Interface to Custom Logic (FPGA, CPLD, ASICs, etc.)
+ Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space)
* System Direct Memory Access (sDMA) Controller (32 Logical Channels With Configurable Priority)
* Camera Image Signal Processing (ISP)
o CCD and CMOS Imager Interface
o Memory Data Input
o RAW Data Interface
o BT.601/BT.656 Digital YCbCr 4:2:2 (8-/16-Bit) Interface
o A-Law compression and Decompression
o Preview Engine for Real-Time Image Processing
o Glueless Interface to Common Video Decoders
o Histogram Module/Auto-Exposure, Auto-White Balance, and Auto-Focus Engine
o Resize Engine
+ Resize Images From 1/4x to 4x
+ Separate horizontal/Vertical Control
* Display Subsystem
o Parallel Digital Output
+ Up to 24-Bit RGB
+ HD Maximum Resolution
+ Supports Up to 2 LCD Panels
+ Support for Remote Frame Buffer Interface (RFBI) LCD Panels
o 2 10-Bit Digital-to-Analog Converters (DACs) Supporting:
+ Composite NTSC/PAL Video
+ Luma/Chroma Separate Video (S-Video)
o Rotation 90-, 180-, and 270-degrees
o Resize Images From 1/4x to 8x
o Color Space Converter
o 8-bit Alpha Blending
* Serial Communication
o 5 Multichannel Buffered Serial Ports (McBSPs)
+ 512 Byte Transmit/Receive Buffer (McBSP1/3/4/5)
+ 5K-Byte Transmit/Receive Buffer (McBSP2)
+ SIDETONE Core Support (McBSP2 and 3 Only) For Filter, Gain, and Mix Operations
+ Direct Interface to I2S and PCM Device and TDM Buses
+ 128 Channel Transmit/Receive Mode
o Four Master/Slave Multichannel Serial Port Interface (McSPI) Ports
o High-Speed/Full-Speed/Low-Speed USB OTG Controller (12-/8-Pin ULPI Interface)
o High-Speed/Full-Speed/Low-Speed Multiport USB Host Controller
+ 12-/8-Pin ULPI Interface or 6-/4-/3-Pin Serial Interface
+ Supports Transceiverless Link Logic (TLL)
o One HDQ/1-Wire Interface
o Three UARTs (One with Infrared Data Association [IrDA] and Consumer Infrared [CIR] Modes)
o Three Master/Slave High-Speed Inter-Integrated Circuit (I2C) Controllers
* Removable Media Interfaces:
o Three Multimedia Card (MMC)/ Secure Digital (SD) With Secure Data I/O (SDIO)
* Comprehensive Power, Reset, and Clock Management
o SmartReflex™ Technology
o Dynamic Voltage and Frequency Scaling (DVFS)
* Test Interfaces
o IEEE-1149.1 (JTAG) Boundary-Scan Compatible
o Embedded Trace Macro Interface (ETM)
o Serial Data Transport Interface (SDTI)
* 12 32-bit General Purpose Timers
* 2 32-bit Watchdog Timers
* 1 32-bit 32-kHz Sync Timer
* Up to 188 General-Purpose I/O (GPIO) Pins (Multiplexed With Other Device Functions)
* 65-nm CMOS Technology
* Package-On-Package (POP) Implementation for Memory Stacking (CBB Package Only)
* Packages:
o 515-pin PBGA Package (CBB Suffix), .5mm Ball Pitch (Top), .4mm Ball Pitch (Bottom)
o 423-pin PBGA Package (CUS Suffix), .65mm Ball Pitch
* 3.3-V and 1.8-V I/O, 0.8-V to 1.8-V Adaptive Core Voltage
 
Last edited by a moderator:
MWeston said:
We are using the 3530.

Ha that explains a lot, especially I was extremely surprised TI would sell 3430 to "low" volume (no insult, it's just that 3430 is probably meant to go to companies that buy several hundreds of thousands of chips).

Thanks for clearing that point :)
 
Last edited by a moderator:
Back
Top