Page 1 of 3


PostPosted: Tue Nov 01, 2016 12:56 am
by jaokim
From time to time, I feel intrigued to do something with Xena. I've looked at Lyle's BufferEx, and tried finding more documentation on the wiki. All I've found is this:
Writing apps for Xena (which talks about the BufferEx)

My aim is to do something where I on the Amiga side can say something like: "Xena, take this chunk of data and process it using all your 8 threads". Looking at the bufferex/localbus example I have a few questions.

(What I write below is far from coherent and understandable. But perhaps someone can explain something with basis on my ramblings.)

1. What is xena.resource for? I'm assuming some of the code in Lyle's example can be replaced by a OpenResource("xena.resource")? Perhaps this:
Code: Select all
uint16 *Xena = (uint16 *)0xF4000000;


   // now we modify the LocalBus timing for Xena
   if((pcidevice = IPCI->FindDeviceTags(
      FDT_VendorID, 0x1959,
      FDT_DeviceID, 0xA008,
      TAG_END)))      // localbus controller
      range = pcidevice->GetResourceRange(0);

Should the above code be replaced with something like:

Code: Select all
   IXena = IExec->OpenResource("xena.resource");

   uint16 *Xena = IXena->AllocResource(XR_DATABUS, "MyAppName");


2. I don't entirely get what everything in localbus.c and BufferEx.xc do. But, it seems that Amiga writes to 0xF4000000, at some offset:
Code: Select all
line 69:   uint16 *Xena = (uint16 *)0xF4000000;
line 245:   XenaWrite(XBUF, CBUF_REQ_DATA);         // will become: (0xF4000000 + (XBUF& 0xFFFE));

Which BufferEx.xc then reads like:

Code: Select all
line 134:      /////////////////// keepout region
line 135:      while(1) {
line 141:      pin_LPC_AD :> addr_low;
line 147:            pin_LPC_AD <: back2Nemo;
line 154:      /////////////////// keepout region
line 155:                if (0 == we)
line 156:                {
line 157:                    pin_LPC_AD :> data; // from Nemo to Xena
line 163:                     if(XBUF == addr_low)
line 164:                    {
line 165:                         switch(data)
line 166:                         {
line 167:                             case CBUF_REQ_DATA:
line 168:                                 bufcon <: data; // Request data
line 170:                                 bufcon :> back2Nemo;      // written back on line 147
line 171:                                break;                           

Now, I don't entirely get this.
Can Xena read arbitrary stuff from what Amiga writes at 0xF4000000? Is this mapped to Xena's hardware? How "long" can Xena read?
Here it reads 16 bytes at a fixed position XBUF. But could Xena read any data here?

One idea I had, was that Amiga writes to pos 1, pos 2, pos 3... pos n, and then Xena does something to pos 1, and writes back the data, and continues wiht pos 2 (or rather pos 9, since it can do 8 things simultanously). And when Amiga is done writing to pos n, it can just read the new data from pos 1.

I'll start like this, and see if anyone has any pointers.

Re: Xena

PostPosted: Wed Nov 02, 2016 12:54 am
by LyleHaze
Perhaps I can help a bit..

Xena has an interface to the "fast localbus" on the Nemo board. This is the same bus that the boot ROM, and the compact Flash, and a few other things that slip my mind right now use.

Any time a program has to write directly to hardware, there is a problem of "what if two programs are both writing to Xena at the same time"?.
So the resource is to arbitrate access. if everybody uses xena resource as prescribed, then we will have no issues with multiple programs tangling up with Xena.

"As I understand it"... the unique (and quite powerful) IO architecture of Xena should have allowed direct bus access without any supporting latches/bus drivers. and the Nemo board
was designed with this in mind. Unfortunately the final result was a bit weak in the driver impedance, and as a result I could never get the localbus interface working as well as I would have liked.
It works, but it's not as fast as I had hoped. :( I suspect this was a by product of die-shirinks as the chip went to production.

I have reviewed (on paper) the design of the X5000, and I am happy to report that these issues have been addressed. The new design supports backwards compatibility, plus a fair bit of what I can only describe as "dual port RAM" which should allow blocks of data to be exchanged rapidly. I'll not give more details until I have personal experience with this. Definition of "block" and "rapid" to be further detailed at some later date.

The unique IO of the Xena chip allows for BLAZINGLY fast serial. The trick is to get to the signal before the level shifters, which are generally the speed limiting link of the serial chain.
The X5000 has a few on-board jumpers that allow a direct connection between the serial port and the Xena chip.. and regardless of the improvements to the fast localbus, there's a real opportunity to go really fast on those pins as well. I think those are labeled "Haze Xorro" or something like that.

Re: Xena

PostPosted: Wed Nov 02, 2016 9:08 pm
by nbache
LyleHaze wrote:I think those are labeled "Haze Xorro" or something like that.
What - not "Free beer and sex"? I'm disappointed ...

Best regards,


Re: Xena

PostPosted: Sun Nov 06, 2016 5:22 pm
by mechanic
In Yahoo Groups A1-X1000 there should/might be some example programs for Xena.

One thing to keep in mind is that the Xmos chip is edge triggered, which makes it respond very fast to changes on its pins.

The following is something I had on the HD of this computer and you might find of use.

Using the Xena to Nemo GPIO on the AmigaOne X1000.


The on-board Xmos chip, Xena, has a one pin port that is connected
to the PA6T CPUs GPIO controller. This is Xena port P1F on XCORE 1
and is wired to GPIO4 in the CPU on the Nemo motherboard.

This pin and the corresponding GPIO input are normally in the HIGH
state and is considered to be active when set to a logic '0' or LOW.

To use the GPIO from the Xena side it is necessary to first configure
the port for OUTPUT by including a line in your program code as follows,

on stdcore [1] : port out gpio4 = XS1_PORT_1F;

the gpio4 designation can be replaced with whatever you like.

To activate the GPIO output it is only necessary to write a zero to
the port using xc standard code.

gpio4 <: 0;

or variables can be assigned to indicate LOW and HIGH values.

unsigned short setOFF = 1;
unsigned short setON = 0;

and then,

gpio4 <: setOFF;
gpio4 <: setON;

On the Nemo side of things you will need to monitor the PA6Ts GPIO
input register to sense any change applied by Xena. The hardware
address of this register is 0xfc103040 in hexidecimal.

You can view where this register is by using the F key to break the
startup as soon as the Menu appears on the X1000, then enter the
following at the CFE> prompt,

show soc sdc.sdcgpio

Notice the line beginning 0xFC103040 is marked as 'in' at the end.
The Value for that address should end in D5. This value is what we
will be looking at to see if Xena has applied a LOW (0) to the input
of the GPIO controller.

D5 in Hex translates to 1101:0101 in Binary. Also, in Binary the bit
positions are kind of backwards being labeled 7-0 from left to right.


The only bit we are interested in is bit 4. By setting bit 4 LOW the
value becomes 1100:0101 or 0xC5. (Using the 0x before Hex numbers is
a standard way of designation).

We simply want to monitor bit 4 and don't really care about the other
bits so we will use a C method known as 'Bit manipulation' or
'bit twiddling'. To test a bit we use,

bit_field & (1 << bitnumber);

In our case 'bitnumber' is 4. Therefore, bit_field & (1 << 4);

We want to set the bit_field variable to as small an amount as
needed. Unfortunately the smallest integer number we can use is
16 bits wide, however character values are only 8 bits wide, so
we will use the C language 'char' variable and assign it thus,

char gpio4;
Now we have, gpio4 & (1 << 4);
Which says compare bit 4 of gpio4 to 1.
Now we need to set gpio4 char to look at our gpio controller.

gpio4 = *(char*)0xfc103040;

Which sets gpio4 to look at the 8 bit value located at 0xfc103040.

We can now monitor and print out the value of GPIO4 by including
in our Nemo code,

gpio4 char;
gpio4 = *(char*)0xfc103040;
if((gpio4 & (1<<4)))
IDOS-> Printf("GPIO4=1\n");

IDOS-> Printf("GPIO4=0\n");


After digging around in CFE to find where the GPIO portion of
the PA6T was I needed a way to determine exactly which bit was
indeed related to GPIO4.

To accomplish this I wrote a small Xmos program that toggled the
pin connected to GPIO4 on and off in 10 second intervals and used
the excellent FileX program by Alfred Faust, available on OS4Depot,
to monitor the GPIO 'in' section.

Using the 'Grab memory' function of FileX and entering values of
Start fc103040 and End fc103044 I could see the first value change
from D5 to C5 in harmony with Xena's toggling of its output port.
(I also toggled the on-board LED in unison with the GPIO port.)

Nemo was designed to use this gpio scheme and as a test of its
durability I ran the Xena toggle program more than 24 hours without

Have Fun

Len Karpowicz

Re: Xena

PostPosted: Mon Nov 07, 2016 4:50 pm
by xenic
mechanic wrote:Using the Xena to Nemo GPIO on the AmigaOne X1000.
On the Nemo side of things you will need to monitor the PA6Ts GPIO
input register to sense any change applied by Xena. The hardware
address of this register is 0xfc103040 in hexidecimal.

Assuming someone writes a program using the information provided in your example program, what will happen if the program is run on an X5000? Will the GPIO input register on an X5000 be at the same hardware address?

Re: Xena

PostPosted: Mon Nov 07, 2016 4:58 pm
by mechanic
xenic wrote:Assuming someone writes a program using the information provided in your example program, what will happen if the program is run on an X5000? Will the GPIO input register on an X5000 be at the same hardware address?

I doubt it, and I would not even try it.
Hopefully there is better technical info for the X5000.

Re: Xena

PostPosted: Tue Nov 08, 2016 6:54 pm
by jaokim
mechanic wrote:In Yahoo Groups A1-X1000 there should/might be some example programs for Xena.

Yeah, I saw that, and applied for membership – however no reply as of yet. Applied a week ago or so.

So, this GPIO on PA6T - should that be faster than flipping one bit on the localbus? All I've heard is how slow the localbus connection is to Xena, but I'd really like to get some sort of working example to experiment with its capabilities.

Re: Xena

PostPosted: Tue Nov 08, 2016 6:57 pm
by LyleHaze
The gpio bit is intended as an interrupt. Not being used now, but may be at some future date.

Re: Xena

PostPosted: Wed Nov 09, 2016 8:11 pm
by mechanic
Like Lyle said, the gpio was supposed to trigger an interrupt. It does not, so you would need to monitor the input from the Nemo side.

Only Xena can turn ON the bit, and only Xena can turn it OFF. If you want to 'Flip a bit' on the Localbus then you would have to read the bus from the Nemo side which Xena may not have ready at that time. When Nemo wants to READ, Xena has to be ready to WRITE. This 'feature' makes localbus transfers less than desirable for large amounts of data. A suitable serial port or even a parallel port would be better. Keep the localbus connection more for command and control.

Think of it more as two separate machines doing their own thing until Xena has something to say to Nemo, at which point Nemo makes decisions and directs Xena in some way.

Re: Xena

PostPosted: Thu Nov 10, 2016 12:34 am
by jaokim
Okay, so, basically, what you're saying is that there's nothing really interesting to do with Xena without actually digging out your solder iron, order some chips and build away? Because there's no real way of transferring any useful data from AmigaOS to Xena and back.

Now, I didn't buy my X1000 with any thought given to Xena - had it not been there, I would've bought the X1000 anyway. But it feels like the integration between Xena and Nemo is kind of uninteresting. Anything you can do with Xena, can in essence be done with a Raspberry Pi - which would actually be easier to integrate with AmigaOS, if I choose a Pi with an Ethernet port. I do acknowledge that the Xmos chip in itself can potentionally do a lot more powerful things than a Pi, but that really has nothing to do with its integration with the X1000.

Or am I missing something? I don't mean to sound negative (but I do feel a lot like all the naysayers). :|