Xena questions

Are there any tools available on amigaos4 that are able to load the xmos chip through jtag? Or do I have to do the bit banging myself?

The only info that I can find concerning xena is PA6T/x1000 centric example on wiki.amigaos.net and something called a xena.resource in the sdk.

Since the local bus is different between the PAsemi and P5020 I was hoping that the xena.resource will at least provide an abstraction and basic needs. Yet, the resource is only about getting exclusive access to xena resources like the jtag interface. Not about getting a base address or actually programming the xmos.

The x1000 example is pointing to sys:utilities/Xena/xtools/xrunxe. But this one is not available on my X5000.

I can see in the X5000 TRM that the CPLD interrupt is connected to IRQ4# of the P5020. How can I get the actual exec interrupt for AddIntServer?

Another concern is that the index pointer is shared between the xena mailbox and diagnostics info.

So I wonder how e.g. fan speed readout of the X5000Temp.docky will bite xena communication.

@geennaam
Quote:I don't know anything about the Xena, but AmigaOS interrupt numbers 0-15 are classic Amiga hardware IRQs and for PCI interrupts on Amiga NG systems you have to add 16 to the hardware interrupt number, for example PCI interrupt 8 is AmigaOS interrupt 24.

@geennaam

If this can help : https://amigaonthelake.com/blog/the-xena-research-project/

@joerg

Ok, I'll try 20 when I've solved the first mystery: Where's the eLBC Mapped. Apparently the LBC on a X1000 is a internal PCI device so you can search for it like a normal PCI device. But the P5020 has it memory mapped somewhere.

@K-L

Unfortunately it's just basic information about the XMOS chip and info that is available in the X5000 TRM

@geennaam

See PM

@geennaam

AFAIK, @Lylehaze has the most experience with XENA/XORRO. He was working on a debug logger. He is the best one to ask about it.

Hans

@geennaam

I ported the tools available on the x1000, from a rather advanced member of the xmos community.
they are bit banged, and not as fast as proper jtag. but they are quite capable, if a bit slow.

Unfortunately the bus interface on the x1000 proved that the xmos chips have weak bus drivers. Trying to make that work was a really rough project.

as a result, the designer made the x5000 using another chip as a bus driver, so it should be able to communicate faster and more reliably.

I've never had an x5000, so I've never had opportunity to port the tools.

the original author from the xmos community is "Segher Bossencool".. or something very close to that.

the software is well designed, with all the hardware interface in a single file, if I recall correctly. I never had any more information than the TRM for the x1000. I suppose the x5000 TRM has the necessary details as well.

That's about all I can think of off the top of my head. you are welcome to ask more, either here or to my personal email.

Lyle haze at gmail dot com

@LyleHaze

Segher Boessenkool

so close

http://git.infradead.org/users/segher/dis-xs1.git

@LyleHaze

Yes, the jtag interface is now buffered with a cpld in between. A bit slower jtag is not really a concern for me. I can also use the spi eeprom instead to do a few tests.

Unfortunately the communication and data interface is completely different from the X1000 as well.

The X1000 local bus is a PCI device which connects directly to the xmos chip.

The X5000 works with a mailbox, index pointer and dual ported ram in between. The index pointer is used to point to the interface or register that you want to read/write The dpram acts as shared memory or return register for e.g. Fan speed. In case of the xmos data interface, the sender writes data and receiver gets an interrupt that data is available. Now you could split the memory area into multiple sections where you simply move objects back and forth in a buffered full duplex manner. Or keep it in one piece as a question answer interface

The good news is that the Upd2 kernel doesn't support this X5000 local bus yet. This means that apps and dockies use the microcontroller to get the fan speed. So no collisions are to be expected. The bad news is that I cannot access this bus yet on my X5000.

@geennaam

I think I understand what your thinking, we know XMOS on X1000 is useless.
its good to know you can use XMOS X5000 for things, put the CIAA/CIAB in the XMOS chip can be doable, putting the Paula chip in there can be tricky, because AmigaOS4.1 does not allocate chip memory, instead CHIP mem is allocated in any address space, we can’t simply trap address range and forward it to an external chip.

Having external chip that can keep precise time, and generate IRQ, can be really useful for audio applications, GPIO pins can easily mapped joystick ports as well. This can improve UAE and native 68k support in X5000. The Sam460 has gpio.resource I believe, can be used for this as well.

Sure there are more things can be done, like temp monitoring and fan speed regulation.

@LiveForIt

It isn't what I have in mind. I want to Benchmark the interface first to see what's possible for difference scenario's.
But sure. The single cycle nature of the xmos chip allows for predictable timing behaviour.
Anyways, for now, access is blocked by the MMU and therefore results in a DSI. We have to wait for a newer kernel which maps the local bus memspace.

The Xena interface can manage overall around 10MB/s half duplex at a first attempt.
This is the result of a simple write full (CPU), read empty (xmos) interface.

With a streaming ping-pong buffer, the interface will be able to manage close to 20MB/s half duplex.

Edit1:
~17MByte/s with a pingpong buffer. Not bad.

Edit2:
~20MByte/s after some optimization.

@geennaam

Wow.

Can't wait to see what you come up with to finally make use of it

@Raziel

I have no intention to create something commercial or open source.

The interface is completely different from what is available on your X1000 so what I am creating is X5000 exclusive anyways.

The A1222 doesn't have a xorro slot and the XMOS XS1 is EOL. If a future next gen amiga will happen and still have a xorro slot, the xmos binary and probably the interface won't be compatible anyways.

Yet, xena offers a "low cost" way to expand the X5000 with custom homemade solutions since it circumvents the PCIe interface and includes a 1000MIPS cpu.

Therefore it would be nice if future A1s would at least offer a (buffered) LBC interface.

Anyways, I've already learned a lot about the features and limitations of the xena interface and XMOS chip. Unfortunately, I have to work around some shortcomings as a result of the implementation.

So I am still in the discovery phase.

Next step is to transform my Xenaprobe into a xena device driver which contains the xmos loader and a configurable communication interface.

After that I'm going to port the C64 SID player with a redirect of the synth samples to AHI as a proof of concept.

If all checks out then I'll start a first hardware project.
This will be a high end audio card with
- high quality DACs
- High Quality ADCs
- High quality OPAMPs
- S/PDIF out
- wave blaster interface (I still have the DB50XG, but there are also new tiny gs wave table synthesizers .


The XMOS can do:
- x Band equaliser
- Audio effects
- SRC
- channel upmixing (eg 2.0 -> 5.1)
- Virtual HP surround
- x ch input audio digital mixing
- multichannel -> S/PDIF (a52 encoder)
- Maybe keep the SID player for fun

I order to connect all the DACs ADCs, I'll need a CPLD/small FPGA to provide the I2S interfaces. It would be a waste to use xmos threads for this pupose

Well now, that sure looks promising

Keep up the good work! @geennaam

The next NG board should be build by you. Then it takes 10 Months instead of 10 years

@geennaam

Keep up the good work! We need more users like you :D

@geennaam

Quote:Interesting!

BTW: There is a warning on the page you link to:

Quote:I can't help wondering whether an AmigaOne would be considered a musical instrument if fitted with one of those and used to create synth music ...

Best regards,

Niels

@nbache

Just fitting the card doesn't make my amiga a musical instrument. Only when I install software which allows me to compose music with it does.

But I think the intention of this warning is that Roland will not allow it if the soundfont is used create a cheap commercial GS Synthesizers, GS electronic keyboards etc.

The card also ships with a second soundfont which is not subject to the Roland IP restrictions. The manufacturer offers PC software which allows you to install your own soundfont on the remaining 48MB flash.

However I do not have the musical skills anyways, so I am not worried at all for Roland lawyers showing up at my doorstep.

As far as I understand, there's a CAMD.library usb driver for amigaOS4. So this means that you should already be able to connect that card to our next gen amigas. You could loopback the headphone output to a line in. That webshop sells external cases as well.

Edit1:

The DreamBlaster-X16GS offers even 1 GB for up to 8 soundfont banks.

@geennaam

Quote:
The DreamBlaster-X16GS page claims that the card's USB MIDI connection is class-compliant, so it indeed shouldn't be a problem to connect the card to an OS4 Amiga system. Lyle's USB MIDI driver works well.

If only there was MIDI software for OS4 I'd want to use