@Hypex

Quote:

Finally we got OS4 and the new Amiga machine and we got crap! Hardly a driver for a common TV card

Are you kidding there are TV cards for PCI that work in AmigaONE / Pegasus II / Sam440 / Sam460. VT some thing.

http://www.amigans.net/modules/xforum/viewtopic.php?post_id=69396

Anyway it is Coax so maybe bit old standard when every thing is HDMI this days.

Anyway if you wan to connect your AmigaONE to the TV, get a simple DVI to HDMI adapter.

Quote:

yet alone possible to display TV behind the OS4 Workbench. I think the Amiga scene lost it then.

That is not called a TV card, that is called a GenLock, it just simple video mixer, I guess you can get a standard one I it will most likely work whit out any drivers.

But maybe I'm wrong, have you investigated?

http://www.ambery.com/4hddvispqupi.html

Last edited by NutsAboutAmiga on 13-Feb-2014 at 02:23 PM.
Last edited by NutsAboutAmiga on 13-Feb-2014 at 02:19 PM.
Last edited by NutsAboutAmiga on 13-Feb-2014 at 02:14 PM.
Last edited by NutsAboutAmiga on 13-Feb-2014 at 01:58 PM.
Last edited by NutsAboutAmiga on 13-Feb-2014 at 01:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hypex

Quote:

possible to display TV behind the OS4 Workbench.

You can use a trick to play video as Workbench backdrop.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@olegil & KimmoK
Do either of you have any estimation how much it would cost to ask IBM, AMCC (or whatever they're called) or anybody else to create your own SoC chip with any selection of cores you want ?

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Hypex

Quote:

Hardly a driver for a common TV card yet alone possible to display TV behind the OS4 Workbench

Not sure what you mean - you mean use the TV card as a backdrop for Workbench? Nobody ever asked for it...

If you can get me datasheets for the later chipsets I'll be happy to add support for them in my TV program (which I originally wrote in about 2006 and which gets sporadically updated). At the moment it supports the most common TV chipsets - the Brooktree Bt848, the Bt878 and the Conexant CX2388x chipsets - as those are in most cards and have open documentation (Linux drivers are not enough, I need the datasheets).

I'm actually thinking of using compositing in future instead of overlay. Not sure if it'd be faster, but would be more OS-friendly.

@Tomppeli

A freakin lot, even on the low end.

Are we talking someone licenses the cores and combines them himself, or is this purely a pay "them" turnkey thing?

You have to pay the core fees.

You have to pay engineer nre fees. (Ie. the work to finish and validate the chip design)

You have to pay for masks. At high performance nodes, a mask set costs millions$. You may have to pay this more than once to fix bugs found in prototypes.

You have to pay for manufacturing costs.

Who has several million $ to do this for "us" ?

_________________
All glory to the Hypnotoad!

@billt

Not to mention that you propably have to order at least 100k units.

@KimmoK

The highest clock P1022 costs about 54USD, aka 40EUR. So you're off by a fair bit.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Tomppeli

Designing a new chip costs millions of USD. Getting a single core version of T2081 as a T2022 would be possible by just cutting out parts of the mask, but then it wouldn't actually be any cheaper to manufacture, except for yield benefits. So what they've designed is what you get.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@custom PPC soc

Custom chip for our niche only would cost too much.
But board designer could ask Verisilicon what their PPC460+GPU combination cost.
(the chip design is done and prototypes have been delivered to at least one customer)
(and it should be found out if we can fully program the GPU)

Last edited by KimmoK on 13-Feb-2014 at 08:51 PM.
Last edited by KimmoK on 13-Feb-2014 at 07:49 PM.
Last edited by KimmoK on 13-Feb-2014 at 06:49 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

Quote:

billt wrote: @Tomppeli A freakin lot, even on the low end. Are we talking someone licenses the cores and combines them himself, or is this purely a pay "them" turnkey thing? You have to pay the core fees.

Let's say we own a synthesizable core modified for performance in an ASIC written in VHDL. We also do all the SoC additions in synthesizable VHDL.

Quote:

You have to pay engineer nre fees. (Ie. the work to finish and validate the chip design)

Shouldn't the design already be tested in an fpga? Is this what can't be validated in an fpga?

Quote:

You have to pay for masks. At high performance nodes, a mask set costs millions$. You may have to pay this more than once to fix bugs found in prototypes. You have to pay for manufacturing costs.

How much are we talking to make 10k and 100k quantities of say 500MHz-1GHz ASICs? How much does the size of the logic increase the cost (say 32 bit vs 64 bit core)?

I expect it's still probably $100k-250k which is more than a few thousand PPC Amiga owners could afford. What if we went back to 68k though? Then we should have tens of thousands of Amiga users that would want one, especially with the Amiga custom chips built into the SoC. There could still be up to 2 GB of memory, PCIe, SATA, USB and ethernet (maybe not support in SoC though). I think a 500MHz+ 68k would seem faster than a SAM 440 but surely slower than high end PPC. Memory would go a lot further and power draw would likely be small (maybe good enough for electronic devices). Some other people in the embedded field may be interested helping to defray Amiga costs. How many PPC guys would buy one though?

@KimmoK

I've never been able to find anything about a product form Verisilicon, only IP cores and design services. Do they actually sell such a product? Can you give a model or a webpage, or any other details? Though as someone mentioned 800MHz, I myself am more interested in Freescale's faster stuff.

_________________
All glory to the Hypnotoad!

@matthey

Quote:

Shouldn't the design already be tested in an fpga? Is this what can't be validated in an fpga?

Taking VHDL to silicon can be complicated, with MANY more things to do than for VHDL to FPGA. A simple chip can be somewhat easy. A processor with lots of IPs, is neither simple nor somewhat easy. I've worked on ARM based SoC designs, using ARM core from ARM and IP blocks from our internal IP group. I've been in the design to silicon trade for 15 years. 8 years or so of drawing FPGA silicon, 5 years of ARM SoC, and a couple years of setting up PDKs and project environments, and helping them use the tools. (PDK is Physical Design Kit, what you get from Fab/Foundry to design stuff to that technology for manufacture)

If you're making an ASIC, then you have a lot of other kinds of verifications to do. You need to redo any VHDL simulations of the ASIC synthesis, as this will be very different than the FPGA synthesis. You will likely (ie, should) add test, such as jtag scan chains, and ATPG structures, perhaps some BIST things, which won't be in the FPGA synthesis. There are a few times this may be run, after synthesis, then after adding test structures and paths to that synthesis, and then after place and route is done.

For cache memories, you're probably going to use some sort of memory block "compiler". This doesn't put code into a memory, it takes parameters and builds the silicon layout of a memory block to your spec. This will need some validations, licensing, and you are extremely unlikely to make your own, even for a MOS SRAM style memory via standard cell place&route. That would be a huge waste of space that a compiler tool or other thing would do far far better and with faster and more consistent performance. These memory IPs are basically very custom silicon layouts, with some automation based on capacity and X to Y dimension ratio.

You need to do timing analysis again, if you did that for an FPGA prototype. The ASIC timing will not match FPGA itming for a variety of reasons. ASIC will be faster as it will not suffer from the overhead of the FPGA architecture. It will likely be a different fab technology than the FPGA was manufactured in. Etc... You probably have different clock domains, and with different IPs may have different power domains to make sure are all OK.

I'm not sure what all you plan to do before running an FPGA board. Are you running a strong test plan in simulation to test all IP connections are present and correct? To make sure that you didn't miss connecting an interrupt line, or an enable, config bit etc. somewhere? You better be doing this for your ASIC before paying for masks... This is a significant undertaking.

You also have physical verifications to do. An FPGA prototyping setup has absolutely nothing to do with these sorts of things. DRC, to make sure no design rules are broken. This looks for different wires too close together, such that they might be likely shorts, or wires to thin, such that they might be likely opens, and checks to make sure that corners and ends of wires or gates are manufactured properly and consistently. Antenna checks to make sure no wire segment is too long without a path to a safe location, as such a too long wire segment connected to a gate can build up a lot of charge during wafer etching and blow the gate. That's now a dead die. Filler, aka Dummy, metals and other layer additions to keep things as flat as possible as things stack up.

ERC checks to make sure other things are OK, so that you won' t have electromigration problems (chip is good off the line, but consistently dies a short time later), things are EMC safe, etc.

Power analysis. Does the metal drawn provide enough current to the entire chip, or are there brownout areas that need wider metal into them? Or that any switchable power domains are all done correctly, including signals entering and exiting?

Thermal analysys. Do the temperatures at different parts of the die cause problems, such as impacting timing? (heat increases resistance, which slows things down, and different temperatures across the die can make things weird, and has to be dealt with)

Then there is LVS. This makes sure your layout matches your "schematic", such as your netlist after adding scan, ATPG and running place and route. This makes sure that no mistakes are made in terms of mask shorts, opens, or wrong connections, wrong cells, or anything outright missing. (Somewhere I have a wafer of some chip that has no memory blocks, someone accidentally deleted them after running LVS, and there are visibly large empty spaces on the things, all of course total junk die. If they had been deleted before LVS, it would have been discovered before wasting a lot of money on masks and wafers. Not a product I worked on, but some friends did.)

You're not going to beat prices to just buy what Freescale already sells off he shelf. Not even the expensive ones. Unless you go in big-money with intent to compete on the PPC market in general. Now you also need to fund a marketing department...


I myself am not all that interested in going back to 68k as "the future". If we're going to take another CPU change, then either go ARM or x64. Preferrably ARM64 or x64, and it's a bit early to do much with ARM64. If we're not going to change to them, then we might as well stick with PPC. To continue with 68k would, for me, require a serious overhaul, and I'm not sure if a result of that would still be "68k". I'd want to see 64bit and SIMD. Similarly, I prefer 64bit PPC with Altivec to 32bit+altivec or 64bit without Altivec, as an Amiga processor if we're staying on PPC.

But, having said that, I am interested in Mininmig, TG68, Vampire, and whatever the Natami CPU is called these days. But that's retro fun, not "future". But if these CPUs do go 64bit etc. then I'll be interested in following such things. But I don't expect that kind of updates for them.

Last edited by billt on 14-Feb-2014 at 02:36 AM.
Last edited by billt on 14-Feb-2014 at 02:34 AM.
Last edited by billt on 14-Feb-2014 at 02:12 AM.

_________________
All glory to the Hypnotoad!

Quote:

billt wrote: Taking VHDL to silicon can be complicated, with MANY more things to do than for VHDL to FPGA. A simple chip can be somewhat easy. A processor with lots of IPs, is neither simple nor somewhat easy. I've worked on ARM based SoC designs, using ARM core from ARM and IP blocks from our internal IP group. I've been in the design to silicon trade for 15 years. 8 years or so of drawing FPGA silicon, 5 years of ARM SoC, and a couple years of setting up PDKs and project environments, and helping them use the tools. (PDK is Physical Design Kit, what you get from Fab/Foundry to design stuff to that technology for manufacture) ... You're not going to beat prices to just buy what Freescale already sells off he shelf. Not even the expensive ones. Unless you go in big-money with intent to compete on the PPC market in general. Now you also need to fund a marketing department...

Thanks. That gives me an idea of the process. We would probably have to find a partner that liked our design for other embedded applications. I think the 68k/ColdFire market would have lower expectations because there is less competition. Despite the demise of PPC, there are still some powerful high tech PPC processors available. They just have embedded features and optimizations instead of the ones Amiga users want.

Quote:

I myself am not all that interested in going back to 68k as "the future". If we're going to take another CPU change, then either go ARM or x64. Preferrably ARM64 or x64, and it's a bit early to do much with ARM64. If we're not going to change to them, then we might as well stick with PPC. To continue with 68k would, for me, require a serious overhaul, and I'm not sure if a result of that would still be "68k". I'd want to see 64bit and SIMD. Similarly, I prefer 64bit PPC with Altivec to 32bit+altivec or 64bit without Altivec, as an Amiga processor if we're staying on PPC.

Have you ever considered PowerPC for the high end of the Amiga market and 68k for the low end? Amiga PowerPC machines already execute 68k code which makes a pretty good and very dense (16 bit) byte code format. An optimized PowerPC JIT may be nearly as fast as less optimized PowerPC code because of the compression and reduced bandwidth needed (Remember IBM's CodePack for the PPC?). 64 bit PowerPC makes sense for workstation performance and can have the needed memory. The 32 bit 68k is perfect for most consumer computers and small electronic devices. The 68k is a memory and cache miser as well as being very powerful in cache/memory yet tolerant of poor quality code. The old quirky 68k has a lot in common with the x86 but no one makes fun of that crappy ISA and old design anymore. We like the fast 32 bit, the ease of programming, the tiny fast loading programs and 2GB of memory is enough to run all but the largest programs and do plenty of multitasking. There is some VHDL for an Altivec like SIMD with 128 bit registers. Of course it has some of the PowerPC memory restrictions removed and gained some nice 68k addressing modes. The SIMD and FPU need a lot of development work though. The nice thing is that we wouldn't be reliant on certain manufacturers and we would control the ISA (and which instructions are trapped). We know we can't compete with x86_64 or ARM64. We will have better code density than Thumb 2 and our tests show that we should be able to compete with low end ARM (without OoO). An enhanced 68k ASIC would probably result in a processor similar to an older lower clocked 32 bit superscalar only Atom but with better code density and less decoding overhead.

Quote:

But, having said that, I am interested in Mininmig, TG68, Vampire, and whatever the Natami CPU is called these days. But that's retro fun, not "future". But if these CPUs do go 64bit etc. then I'll be interested in following such things. But I don't expect that kind of updates for them.

The fpgaArcade is innovative and looks like a lot of fun if they ever get to producing it in quantity. It could do well with a good Amiga core and enough old console cores. 68020 compatibility and AGA are a big step up from the MiniMig. The Natami CPU is currently (internally?) named the Apollo core and targets a Cyclone V or larger. There is a smaller variant that is being configured for a Cyclone II but I probably shouldn't say too much about that. The web site is still up but most of the info is older:

http://www.apollo-core.com

The performance benchmarks are kind of old now but they do show the performance of the cache design and the advantages of a good CISC design working with cache/memory. I may have to look you up for more advice later. Thanks for your input.

@matthey

Actually, if you are somewhere above the volumes where FPGA makes sense (high per-unit cost) but below the ASIC levels (high up-front cost), then you should look into a program that at least Xilinx does, where you buy chips which are only tested for your specific design. That means you can't change things later, but you only pay a fraction of the cost of the R&D.

The name of the Xilinx version is Easypath. Though it's only available for V6, K7 and V7. NRE is 300.000 USD. If that sounds like a lot, don't even consider doing an ASIC. The per-unit cost of the FPGA is reduced by 35%, which means you'll need to have FPGA costs of about 860.000 USD for a specific design to consider it.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@matthey

>Despite the demise of PPC,



> there are still some powerful high tech PPC processors available. They just have embedded features and optimizations instead of the ones Amiga users want.

What do Amiga users want for a CPU?
Highest possible performance? x64 and POWER do that and then is PowerPC.
Do we have apps that make a CPU like 1.4Ghz multicore PPC insufficient? (a-eon design supports up to 2.5Ghz P5040, IIRC)
(and we still do not have product with latest PPC cores + the NGCore is planned to have focus in improving signle thread performance)
The world is moving towards GPU use in heavy math. Perhaps we should head there as well (CPU ISA does not matter much then).

>The 32 bit 68k is perfect for most consumer computers and small electronic devices.

I think that is not true. Already our systems require more than 512Mb to be usable and for power users the 32bit maximum of 3Gb is too limiting (even I would like to use more than 4GB for video things). And when we have that 3GB for applications, how can we then handle the 2Gb addresspace of common 3D GPU cards? 64bit is pretty mandatory outside retro use.

IDEA for FPGA guys:
-develop AAA in FPGA, to be used in embedded devices + low end AmigaLike machines (with big or little endian CPU)
(it would be nice if we could have a "standard" component for 2D and audio, so that we would not need to recode audio drivers for every new motherboard)


"My Amiga" or "Amiga for me":
-all (90% or more) AGA features done with modern GPU+CPU
-RTG and RTA because we need to use third party components
-simplicity, familiar system, reliable system, efficient
-flow of modern features without breaking old ones (legacy SW compatibility is not mandatory, but very nice)
-own new features, not just copying mainstream
-fast enough to do all basic desktop computing with even low end machine
-flexible systems that can be built/extended to high end, capable all needs (performance wise)
-affordable
etc...
To me, modern PPC seems good for those needs. (CPU does not need to be the fastest, the history shows that)

Last edited by KimmoK on 14-Feb-2014 at 09:03 AM.
Last edited by KimmoK on 14-Feb-2014 at 08:33 AM.
Last edited by KimmoK on 14-Feb-2014 at 08:31 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

This AAA obsession of yours really confuse me. But I do have an idea.

Straight AGA for normal Amiga compatibility (I would think this is already done), then add a few of framebuffers (as many as possible, really) with selectable scaling, filtering and color space conversion. Let the AGA parts choose where on the screen the framebuffers will be placed, just like normal windows (not overlay, as that sucks). Next one fills up the FPGA with shaders that can output to one framebuffer while using the others as textures, with scripts written like the copper lists of old. And then you write software for using the shaders for 3D and video decoding.

It might sound crazy, but there you have your custom GPU, backwards compatible and while not being superior to the current offerings in most ways, the way the OS and the GPU would interact would be far, far, beyond anything we're seeing now, and a rather small team of dedicated people CAN actually make this work.

I would back this. If anyone wants to discuss this with me, I'm all for opening a new thread. But the usual suspects would of course try to drown any such discussion in noise about how nvidia or ATI are better. Even though we all know they are not, since we don't have any overlay/video texture or 3D support for those chips that would actually outperform a homebrew FPGA solution.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegilAGA

That would beat "DIU" any day!

Any example of what kind of FPGA would be enough? And it's cost?
And how demanding would that be to CPU interface, would PCIex1 be enough? Perhaps PPC local bus even?

@old custom chipset things... anyone remembers Caipirinha?
http://www.amigahistory.co.uk/aboxspec.html

Last edited by KimmoK on 14-Feb-2014 at 09:16 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@olegil

Quote:

But the usual suspects would of course try to drown any such discussion in noise about how nvidia or ATI are better.

I guess your thinking about me, well I think writen what I think about AGA, no need to repeat it, just sick of people saying AmigaONE is not Amiga, we know, we know, and thats not a bad thing

about your idea, I have writen about some like that before, and yes doing AGA in a frame buffer is some thing I belive might be good idea, not because AGA is best thing ever, but because of legacy.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

... to the people who are say AmigaOne is not amiga i can reply ... yes if you think about amiga classic, but if Commodore was alive in 1996 im pretty sure will make the same chose of Eyetech in 2002 (Xe and Micro was the first AmigaOne)
Probably today Amiga will be or On PowerPc cpu or on X86 (like apple)
or Amiga division can was totally close from commodore like was the Vic or C64 for make a new brand ...

in any way the important is we have in 2014 the Amiga feeling alive thanks to Aeon, Acube, Hyperion and Mos team plus all the company/devs who are making software for this "small,undead, survivor, hobbyst" platform.

Yes i can say to Trevor why not ask the guy who make the FPGA project like Chamaleon/ Minimig on Xorro/PCI board with Aga/ECS for the 100% compatibility?
I have a Chamaleon 64 and i can say for sure this kit is 100% compatible with all ECS games from me tested (some are not running good on uae) and gave a really good performances in wb emulation.

Last edited by tlosm on 14-Feb-2014 at 09:57 AM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@billt

I saw results of a lame-test comparing different platforms where "emulated" 68k was on the same level as 500 Mhz PPC. 68k is much more diverse today, there is Amithlon (what was a great product and sadly was stopped), there is the 68k community still developing software, most documentation, dev environments and applications in use are 68k, much more users are 68k than all NG camps combined. Thanks to UAE 68k runs almost everywhere and I try to do my small part with AROS Vision and AMINUX (with help of Pascal). 68k also offers great dev libraries like "Game Master System" with highly optimized assembler who could potentially help a lot (if really used). I have also AHI and Truecolor on 68k. I think there is a lot of potential in 68k that many "NG" users not see or do not want to see.

I personally will not only try to improve AROS Vision further but also optimize it better for real classic hardware and future FPGA designs. It would unify all 68k platforms, running on classic hardware, FPGAs, on a Stick (AMINUX), on its own (FS-UAE, WinUAE on Windows, Linux, Mac) and for 68k emulation in Aeros. Icaros has its own special integrated Aros 68k with less components but is at least similar. So one OS for the whole 68k platform. That was my "Vision" behind it already for a long time

Imagine running a game based on a highly optimized game lib written in assembler for slow hardware on a system comparable to 500 Mhz PPC. For me that sounds very promising . People should stop looking at it as "retro", basically 68k is a compiler target. Perhaps there could be software that needs performance above any classic hardware but this won´t be a big problem in future (with FPGA and UAE)

Last edited by OlafS25 on 14-Feb-2014 at 10:46 AM.
Last edited by OlafS25 on 14-Feb-2014 at 10:03 AM.