@Hammer

Quote:

The context was "Modern multicore processor". 6510 is hardly a "Modern multicore processor".

I already addressed why the "modern multicore processor" angle (by which I take you mean "fast multicore processor" as there's a bunch of "modern multicore processors" - like the XCore - that have other goals than raw performance) is uninteresting. It's low latency + hard realtime + gpio that is the point of the XCore. And the specific bit I replied to when I mentioned the 6510 was available gpio pins.

I mentioned it specifically to point out that "just" having gpio available on it's own is *not enough*, or a 6510 would be sufficient - you need the "whole package" (latency/realtime/io pins) for many of the applications some of us are hoping for.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@Hammer

Quote:

To quote

You quoted the grandfather of your post. Look at the post you actually replied to, and you see bidirectional GPIO mentioned --- and while HyperTransport and QDI are bidirectional, they are a long way from being GPIO.

So, if not in response to "bidirectional GPIO", why *did* you mention QPI?

@vidarh

Quote:

vidarh wrote: @Hammer Quote: The context was "Modern multicore processor". 6510 is hardly a "Modern multicore processor". I already addressed why the "modern multicore processor" angle (by which I take you mean "fast multicore processor" as there's a bunch of "modern multicore processors" - like the XCore - that have other goals than raw performance) is uninteresting.

To quote back
"I mean if it takes like 256 of them(1) to equal a modern multicore processor why not just stick a second multicore processor in the thing and be done with it

1. I assume "them" to be referring to the XCore product. So, what else can "modern multicore processors" be?

Quote:

It's low latency + hard realtime + gpio that is the point of the XCore. And the specific bit I replied to when I mentioned the 6510 was available gpio pins. I mentioned it specifically to point out that "just" having gpio available on it's own is *not enough*, or a 6510 would be sufficient - you need the "whole package" (latency/realtime/io pins) for many of the applications some of us are hoping for.

On the context traditional PCs, Intel ICH6/7/8/9/10 includes GPIO.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@umisef

Quote:

PCI, or PCIe? Because it would need the latter.

You can find prototype boards with practically any card edge you might ever care to have, as well as with "generic" ones that needs to be cut into shape and/or etched. Many of the ones I've seen online are massive rip-offs, though, since a lot of them are geared at "who cares about cost, we only need one" corporate users.

Quote:

I have very fond memories of my Memotech MTX500. It had an empty 20 pin DIP socket inside, with 8 inputs and 8 outputs, as well as a "printer port" at the back of the machine which was a 34pin 2.54mm header. Both were trivially connected to ribbon cables.

Sounds fun. Something like that would be perfect :)

The C64 was quite simple to connect to as well, with both the user port and datasette port using generic io, and the cartridge port offering direct bus access... And of course the beauty of most classic computers, including both the C64 and classic Amiga's of having everything on sockets...

I had stuff soldered all over the place, including pins of the CPU (halt and reset pins on my 68k, since the side port on my A500 was already taken up by my hard disk). And I have fond memories of resetting my C64 by shorting the reset pin on the user port with the ground wire from my datasette...

Before I got old enough to know better, I remember unseating the 6510 in my C64 and the 6502 on my 1541 disk drive and switching them around because I was curious what would happen (not very useful seeing as some of the io pins on the 6510 in part is wired up to do the bank switching of the ROM, but at least they're pin compatible apart from that)

And I was "saved" while waiting for spare parts more than once by moving a 6526 from my C64 into my Amiga in place of one of the 8520's. Hey, slightly different functionality, but mostly the same, so who'd notice? (unless you tried using the 32 bit timers that is - I did the same with the CIA's in the 1541 at some point - can't remember if they were 6526's or some other mostly pin compatible variation...)

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@umisef

Quote:

umisef wrote: @Hammer Quote: To quote You quoted the grandfather of your post. Look at the post you actually replied to, and you see bidirectional GPIO mentioned --- and while HyperTransport and QDI are bidirectional, they are a long way from being GPIO. So, if not in response to "bidirectional GPIO", why *did* you mention QPI?

Intel QuickPath Interconnect is a point-to-point processor interconnect developed by Intel to compete with HyperTransport.

General Purpose Input/Output (a.k.a. GPIO) is an interface available on some devices. A microprocessor, microcontroller or interface device may have one or more GPIO connections to interface with external devices and peripherals.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

ntel QuickPath Interconnect is a point-to-point processor interconnect developed by Intel to compete with HyperTransport.

Precisely. Which is not GPIO.

Here is a simple rule-of-thumb: If you can't trivially hook up an LED and make it blink, it ain't GPIO. If you can't trivially hook up a push button and read it, it ain't GPIO.


So, why did you feel the need to bring up processor interconnects in response to a GPIO requirement?

@umisef

Quote:

umisef wrote: @Hammer Quote: ntel QuickPath Interconnect is a point-to-point processor interconnect developed by Intel to compete with HyperTransport. Precisely. Which is not GPIO. Here is a simple rule-of-thumb: If you can't trivially hook up an LED and make it blink, it ain't GPIO. If you can't trivially hook up a push button and read it, it ain't GPIO. So, why did you feel the need to bring up processor interconnects in response to a GPIO requirement?

The Intel X58 (Tylersburg) is an Intel chip designed to connect Intel processors with Intel QuickPath Interconnect (QPI) interface to peripheral devices. ICH10 includes the "GPIO".

PCI\VEN_8086&DEV_3422.DeviceDesc="Intel(R) QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers

Last edited by Hammer on 13-Jan-2010 at 10:44 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

There are hard realtime extensions for practically any modern OS. That's pretty much irrelevant on it's own without knowing the latency guarantee, since hard realtime support only guarantees deterministic scheduling, not that the scheduling will be fast. In many cases hard realtime support is done in ways that makes it "usually slower" than normal scheduling in order to be able to make those promises.

I'd be extremely surprised if a virtualized (or non-virtualized for that matter) RTOS on a mainstream x86 model could achieve latency in the low microseconds range without at the very least eating a substantial portion of CPU capacity.

Anything that causes the CPU cache to get flushed for example would ruin any hard realtime guarantees below that immediately; an L1 miss could possibly be tolerated in that kind of scenario, but an L2 miss would be devastating if it occurs at the wrong time. So for a modern CPU used for a desktop OS to get anywhere near the latency guarantees of an XCORE you'd pretty much need to guarantee the working set fits fully in the L2, which would cripple the OS... Or.. It would need to do what On TIme does:

You might notice that the OS you linked to is mentioning "microseconds latency", and their test video shows ticks taking on average 499.9 micro seconds on a Core Duo.... i.e. the XCORE can deliver 4 magnitudes better latency. To achieve that 4 magnitudes worse latency with On Time, you waste an entire x86 core...

Now, that is a *good* tradeoff if 500 microseconds is good enough for you and you need the high *throughput* that core can offer, but if you don't need that throughput it's a horrible waste of a relatively expensive core, and if you need lower latency it's useless.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@Hammer

Quote:

The Intel X58 (Tylersburg) is an Intel chip designed to connect Intel processors with Intel QuickPath Interconnect (QPI) interface to peripheral devices. ICH10 includes the "GPIO".

In other words it takes an extra chip to provide the GPIO. You're not reducing the complexity in any way over adding an XCore.

Which makes it a tradeoff between what you think your most important use cases will be: High throughput (in which case X58 or ICH10 are likely the better options) or low latency (in which case XCore absolutely destroys those alternatives, even with an RTOS running on a core of the main CPU).

Though if you need high throughput and don't care much about the latency, why wouldn't you just use the PCI bus in the first place?

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@vidarh

Quote:

vidarh wrote: @Hammer There are hard realtime extensions for practically any modern OS. That's pretty much irrelevant on it's own without knowing the latency guarantee, since hard realtime support only guarantees deterministic scheduling, not that the scheduling will be fast. In many cases hard realtime support is done in ways that makes it "usually slower" than normal scheduling in order to be able to make those promises. I'd be extremely surprised if a virtualized (or non-virtualized for that matter) RTOS on a mainstream x86 model could achieve latency in the low microseconds range without at the very least eating a substantial portion of CPU capacity. Anything that causes the CPU cache to get flushed for example would ruin any hard realtime guarantees below that immediately; an L1 miss could possibly be tolerated in that kind of scenario, but an L2 miss would be devastating if it occurs at the wrong time. So for a modern CPU used for a desktop OS to get anywhere near the latency guarantees of an XCORE you'd pretty much need to guarantee the working set fits fully in the L2, which would cripple the OS... Or.. It would need to do what On TIme does: You might notice that the OS you linked to is mentioning "microseconds latency", and their test video shows ticks taking on average 499.9 micro seconds on a Core Duo.... i.e. the XCORE can deliver 4 magnitudes better latency. To achieve that 4 magnitudes worse latency with On Time, you waste an entire x86 core... Now, that is a *good* tradeoff if 500 microseconds is good enough for you and you need the high *throughput* that core can offer, but if you don't need that throughput it's a horrible waste of a relatively expensive core, and if you need lower latency it's useless.

"Multi-core INtime platforms exhibit the very lowest real time system jitter, with worst case interrupt latency measured as low as three microseconds."

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@umisef
Seeing as the thread is still on top I might as well respond on this personal note.
Quote:

You *do* realise that neither XCore, the company, nor XCore86, their x86 SoC product (a rebadged Vortex86), has anything whatsoever to do with XCore, the "customisable silicon", from Xmos, the company, right?

Yeah, I know. It was just something I came across in searches that was interesting. Then he said bridgeboard, and although I kinda thought he was talking about something else I thought I'd float the idea just the same. Putting an XCore86 in an Amiga would solve a lot of problems, and would be very, very cool. One barrier that has broken down, which is leading to a lot of the Mac's success, is the ability to run windows apps. It's made me consider it for the first time. Someone with a next gen Amiga should seriously look into the PC Bridgeboard idea at some stage as it too could break opposition to buying an entirely different architecture. Hosting other OSes in hardware is also in the Amiga tradition. The XCore86 board probably costs less than the software required to achieve it on the Mac.

In fact I wonder if it would be possible to turn the FPGAs which are supposed to be present on SAMs into an x86, just for fun. It'd be slow but probably usable in a crunch.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@Hammer

Quote:

"Multi-core INtime platforms exhibit the very lowest real time system jitter, with worst case interrupt latency measured as low as three microseconds."

Their video showed 500 microseconds scheduling ticks though. 3 microseconds is decent, though still in line with what I said (having to reserve a full core certainly qualifies as "eating a substantial portion of CPU capacity"), and that still means they trail the XCore by 3 magnitudes (EDIT: Sorry - two magnitudes, not three; still...) and you still spend a whole core to achieve it just to avoid the $5-$7 cost of an XCore, and you still don't get the gpio lines without a separate chip.

As I said, false economy unless you need the throughput more than the latency.

Last edited by vidarh on 13-Jan-2010 at 11:05 AM.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@vidarh

Quote:

In other words it takes an extra chip to provide the GPIO

Besides the GPIO, ICH10 provides other services required for a modern desktop PC.

Quote:

Which makes it a tradeoff between what you think your most important use cases will be: High throughput (in which case X58 or ICH10 are likely the better options) or low latency (in which case XCore absolutely destroys those alternatives, even with an RTOS running on a core of the main CPU). Though if you need high throughput and don't care much about the latency, why wouldn't you just use the PCI bus in the first place?

Why the black and white? High throughput or low latency?

Refer to Intel Atom (X64) with Hyper-Threading

"Intel Atom processor allows the ultra-low-power and low-cost processor to respond to external events with latency under 10 microseconds".

RTOS without MS Windows bloatware
Refer to http://www.directinsight.co.uk/products/venturcom/ets.html

Transmeta Crusoe 5800 - 1GHz
Hardware ISR Time: 2 microseconds (µs)
ISR Time to Activate Thread: 15µs
Context Switch Up to Higher Priority Task: less than1µs
Undirected Yield from Sleep() : less than 1µs

Pentium II - 450MHz
Hardware ISR Time : less than1µs
ISR Time to Activate Thread - 7µs
Context Switch Up to Higher Priority Task - 1µs
Undirected Yield from Sleep() : less than 1µs

Pentium IV - 3GHz
Hardware ISR Time : less than 1µs
ISR Time to Activate Thread - 5µs
Context Switch Up to Higher Priority Task - 1µs
Undirected Yield from Sleep() : less than 1µs

Last edited by Hammer on 13-Jan-2010 at 11:52 AM.
Last edited by Hammer on 13-Jan-2010 at 11:50 AM.
Last edited by Hammer on 13-Jan-2010 at 11:49 AM.
Last edited by Hammer on 13-Jan-2010 at 11:39 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

"Intel Atom processor allows the ultra-low-power and low-cost processor to respond to external events with latency under 10 microseconds".

You'd still need to waste an entire core to get hard realtime at that level, and that's still 3 magnitudes worse latency than the XCore, and you still need an extra chip to get gpio lines as far as I know.

But fair enough: If you need higher throughput than an XCore but not nearly that of one of the fast x86's, and you don't need gpio, and are ok with 10us latency, it's a better alternative than one of the big, expensive x86 cores... I'm sure there are other options on the scale as well.

Still, an x86 core so it has no bearing on an Amiga.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@vidarh

Quote:

vidarh wrote: (SNIP for space) But fair enough: If you need higher throughput than an XCore but not nearly that of one of the fast x86's, and you don't need gpio, and are ok with 10us latency, it's a better alternative than one of the big, expensive x86 cores... I'm sure there are other options on the scale as well.

Atm, cheap price doesn't translate well with neo-Amigas PC...

Quote:

Still, an x86 core so it has no bearing on an Amiga.

Xcore uses a custom ISA (e.g. 12 GPRs model) and IcAROS currently runs on X86.

Anyway, http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=AUTOMOTIVE-LINUX

"AGL meets specific automotive industry requirements such as real-time determinism, fast boot-time, quick in-vehicle bus communication response time, and a small footprint. With an average user space latency of 50 microseconds and 48-microsecond worst-case interrupt latency under heavy load"

Why “Amiga” is focusing on embedded not a multi-media PC?

Last edited by Hammer on 13-Jan-2010 at 12:20 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

AmigaOS is not supposed to run *on* XMOX, but supporting it as coprocesor.
But that does not change the issue that the XMOS is nothing else than a uC added to the system which could be done with a PCI(e) card (or I2C connection) a s well, since all the fast RT capabilities work only within the XMOS own programs. As soon as interaction with the AOS (i.e. the host processor) is required you need an interrupt on the host processor anyway - and that could be done by a PCI(e) card (or I2C or legacy RS232 or, with limitations, even on usb) as well.
And the idea that the cost of the board gets increased by only the cost of the chip is a milkmaid calculation: You invest in R&D, you need a connector, you need real estate on the pcb and putting the IC on the pcb costs time (=money). The cost of a board is more than the sum of the cost for the ICs.

Edit: I should learn to type "th"!

Last edited by Zylesea on 13-Jan-2010 at 12:34 PM.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Hammer

Quote:

Xcore uses a custom ISA (e.g. 12 GPRs model) and IcAROS currently runs on X86.

Irrelevant. The Xcore isn't intended to run an OS, and I don't see a rush of Amiga users flocking to X86 to run IcAROS. Even if there is, the Xcore in the X1000 obviously has no bearing on users that choose to run IcAROS on off the shelf x86 hardware, so continuing to discuss the x86 in that context is pretty pointless.

Quote:

Why “Amiga” is focusing on embedded not a multi-media PC?

I've already given a long list of apps I find interesting, and clearly other people here find it interesting too given the amount of discussion, and there's a long legacy of hardware hacks for the Amiga.

I don't see what multimedia has to do with this at all - the issue here is the merits of integrating a single $5-$7 part that provides capabilities that the main CPU does not. I argue the size of this and related threads show that it has clear merit regardless if even most people never end up using it - if it helps tip the edge and secure just a few handful extra sales, that's a big deal with a market as small as the Amiga market today. And I know for a fact it is part of the reason that makes me excited about the X1000.

The same amount spent on multimedia capabilities on the other hand would not bring the X1000 any closer to competing on multimedia with anything. It's not like the Amiga today will suddenly get a GPU or other custom chips that aren't available for PC users at the same price.

So for that cost you've gotten a feature that is exciting for a niche. We'll have to wait and see how important that niche will be in bringing A-Eon extra sales, but it's a low cost, low risk bet, and one I for one is happy they've made.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@Zylesea

Quote:

But that does not change the issue that the XMOS is nothing else than a uC added to the system which could be done with a PCI(e) card (or I2C connection) a s well, since all the fast RT capabilities work only within the XMOS own programs. As soon as interaction with the AOS (i.e. the host processor) is required you need an interrupt on the host processor anyway - and that could be done by a PCI(e) card (or I2C or legacy RS232 or, with limitations, even on usb) as well.

You are assuming that it'd be used for tasks where the same volume of data and/or the same realtime capabilities would need to be transmitted between the XCore and the gpio lines and between the XCore and the main CPU, which is true only for a subset of possible uses. I.e. for signal processing you'd only send a command to adjust parameters of the processing function between the main CPU and the XCore.

It's also well established practice to buffer realtime interaction so the main CPU does not need to offer low latency hard realtime capabilities as long as it can offer sufficient *throughput* - after all that is exactly what UARTs are for, except a UART is a dumb device that only handles a single type of connection.

Quote:

The cost of a board is more than the sum of the cost for the ICs.

True, but it's not going to be a significant cost.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@vidarh

Quote:

Sounds fun. Something like that would be perfect :)

There is a reason I am sad to see the parallel port become "legacy", and it has nothing to do with printers :)
The MTX series was a dream. very robust, too, because almost everthing was 74 series, and it was over-engineered. At some point, we had developed a 16 CPU (HD64180 Z80 derivative) for the local equivalent of Science Fair. Ended up exhibiting at the Hanover Industry Fair --- but when we arrived, we realised that we left the power supply at home (ouch!). The MTX (which was used as a frontend slash development box) ended up supplying power from its 5V line for a whole day; Each of the 64180s was driving a high-brightness LED, and whenever most of them were on, voltage dropped enough for the video output to break down, but both the MTX Z80 and the 16 64180 kept going.

Quote:

The C64 was quite simple to connect to as well,

Yep, also fond memories. Except the damn 6526 were too damn fragile (they *really* didn't like being driven below ground level, even for very short times).

Quote:

including both the C64 and classic Amiga's of having everything on sockets...

I know that quite a few C64s I blew up *eventually* had everything socketed --- but in Germany, they sure didn't come that way; It was a matter of solder-sucker-to-the-rescue...



Ah, good old times. But if I were to give in to temptation, I would surely use USB-attached GPIO these days (or USB-attached uController of some sort, which then has GPIO).
Anyone got any idea what the idle power consumption of the XCore development kits? And how it compares to, say, an Arduino?

@Hammer
Once upon a time Hammer discovered that PCs are better than Amiga. Now he can't stand those that still haven't realized "Za Truthhh", and he is here on a mission.
Convince the Amiga crowd to join the Borgs! (we are Intel, Resistance is Futile! ).

I could go out repeating that having Xcore standard will make people use it on Amiga, while all the optionals in the world does not entice any particular focus on other platforms, I could say that, moreover, Xcore is just something more on X1000, which enriches it (makes it a playful machine actually) without precluding other tecnologies such as GP-GPU. I could add many other things....

After seeing you participating in every Amiga thread (including those relating to classics) with an ALL-OUT crusade at demonstrating how Amiga is inferior to PCs I believe you have a serious problem.

Relax.

We don't know everything about this computer and before telling everyone how in fact A-eon are but a bunch of morons for doing this and that, I would question my motives as of "why" I'm doing it at all. Illuminate the ignorants? Tell them PC this and PC that even though they might be posting from a 2000 eur PC rig? (hint).

Come on...

_________________
SamFlex Complete 800Mhz System + AmigaOS 4.1 Update 4
Amiga 2000 DKB 2MB ChipRam GVP G-Force040 Picasso 2 OS3.9 BB2
AmigaCD 32