A new version to test: https://jaokim.github.io/files/XTools-1.7e.lha
Maybe also do a reboot if this shows same or weirder results.

@FlynnTheAvatar
Thanks for quick test!

They are indeed very strange. I don't know if there's some sort of weird caching issue... or have I done something totally weird. I'll see if i can come up with something new.

I've created a new test-version of XTools version for X5000.
It now tests a few calls with differing delays. The longest delay is 10 ticks, but it also tests with 2 and 5. If anyone could
you must read the X5000 section in XTools.txt in the archive to know how to test it. Archive is here: https://jaokim.github.io/files/XTools-1.7d.lha Very beta. I'm not responsible if anything breaks your machine.

@FlynnTheAvatar

Great, thanks for testing!

Seems I don't release the XTAG resource when doing Ctrl-C in that test. Regarding the reads and writes, I've seen similar result for another X5000 user, so it's good to see that it's the same for you.
I'm in contact with some other developers so I hope to get something working for X5000 soonish.

I've added an example of some Xena localbus communications here:
https://sourceforge.net/p/xena-examples/code/HEAD/tree/

It should build out of the box and work on X1000. It's not too much code, and it just implements a simple circular stack so should be relatively self-explanatory. Might try and write something up on the blog explaining some more about it.



Oh, and yeah, this doesn’t require any extra hardware, it should just work on the plain X1000. It won’t work on X5000 even if you got it on to that chip since the localbus interface is way different.

Well, it’s usefulness I don’t know about… but honestly, I could say the same about Amiga in general . Anyways, Xena can do stuff on its own, and basically offload the cpu. The example I have on my blog (https://jaokim.github.io/amiga/2025/10/27/threading-water.html) is absolutely useless, but it shows that we can calculate a value on Xena and see it on the Amiga — no other peripherals involved.
So I think the uselessness of Xena has been greatly exaggerated, although its usefulness might not live up to the hype it got initially.
Lyle did get the localbus communication working, and I’ve managed to create some sort of data exchange scheme. Don’t know the exact speed, but it’s not as slow as jtag.

So, yes, Xena can do something without any extra add-ons — but I think it gets more fun when adding stuff.

So, in os4depot's queue there now exists a new version of Gabrielle, including a set of updated XTools.

I finally managed to get the PLL stuff working allowing the Xena chip to run in full speed, and getting some localbus communication working. I also managed to make it quite a bit faster when working with smaller programs.

I've also added -very experimental- X5000 support. It currently mostly tries to write and read to some registers to get the JTAG communcation running. Any help in testing this is highly appreciated! It currently doesn't work, but it does something, and I need to find out more. There are more instructions in the archive -- please read. It's not super straight forward, for reasons.
A previous X5000 version has been tested on an X5000 with some success. I've tested it on my micro A1 (it obvisouly doesn't do much there, but I tested it to make sure it didn't crash or caused major havoc. But I take no responsiblity!

And I’ve also tried archive.org, asking AI etc to no avail.

Does anyone here have a copy or fork of the dis-xs1 sources from: http://git.infradead.org/users/segher/dis-xs1.git?

In my Xena adventures I’ve found that the XTools XRunXE doesn’t set the xs-1 chips PLL registers correct causing it to run too slow to handle any localbus communication. I’ve got a copy of a later XRunXE v 1.3 from a 2013 binary that did some stuff to the PLL register that made the localbus example work, but I don’t have the sources. I got it from Lyle many years ago, but he’s lost the sources.
The sources in the XTools drawer on my x1000 are older than 2013, so doesn’t have the PLL things.

I’ve asked around on xcore.com and contacted the original author but as of yet to no avail. Hoping someone here is a source code hoarder…

Pressing F2 usually allows you to edit strings. Or triple click?

So I’m reading the X5000 TRM.

It says in order to write to the xjtag I should write 0x000D to address 0x0, and then write the JTAG data to address 0x8000. I’m pretty sure I need to do that relative to where the CPLD is mapped — how do I know where that’s mapped?

The X1000 TRM says that its CPLD is on chip select 5 (page 17), which gets translated to 0xf500000 according to jtag.c. I however can’t find where I can see that chip select 5 equals 0xf500000.
Also I can’t find any such chip select info in the X5000 TRM.

Does anyone have anymore info on this?

I wrote up some more comments regarding the examples in Gabrielle on my blog.

I also put the XTools source up on sourceforge with another blog post on some details for that. I id some reading in the reference manuals and might have found some ideas on how to get the tools to work on X5000, but I have to get some second opinions on that. Will surely come back to that.

Hmm.
I wonder; does this thread indicate the XTools doesn’t work on the X5000?
https://www.amigans.net/modules/newbb/ ... id=143867#forumpost143867

I mean, when the effort was taken to make the X5000 better wrt to Xena, yet no-one bothered to port the tooling? Is there even some documentation surrounding the details?

Thanks guys! I have a few ideas on some stuff I’d like to try out and experiment with.

I’d really like some feedback on how it works/if it works. I’ve got some response from an X5000 user where there seems to be some issues.
General question: has anyone tried any Xena stuff on the X5000? Like the wiggle demo in the XTools drawer?

@sailor
I’ve been trailing the webs for stuff like that. There’s Lyle's buffer example on the AmigaOS wiki, and I also found some posts in the Hyperion forums with more info. I’ve been thinking of trying to summarise that info into something, we’ll see if I ever get to it.

But in general on the X1000 it seems the local bus have some severe limitations. But there are ways to send data to the chip in a slow way using the jtag. But hopefully being able to compile on the amiga will make it less awkward to test things out.
Also, there are some old Xmos resources for our chip that explains the basics. So those are rather good.

I’ve had this project ongoing for years now, and now I finally managed to get something working. Meet Gabrielle — the friend of Xena!

Gabrielle is a script that’ll let you use a remote server to compile your .xc Xena sourcefiles. So now it’s way easier to at least try to do something with Xena.

I’ve tested it on my X1000, but I would love to hear from you X5000 owners!

Read more and get the archive, with some examples and a handy test console at my blog: https://jaokim.github.io/amiga/2025/10 ... ntroducing-gabrielle.html

And needless to say — I’m not responsible if you break your amiga using this software.

@rjd324

Is that perhaps the race condition?
When you press the ok button, the input string gadget looses focus, and it’s content is “registered”, but when you press enter, the enter is seen before the input string gadgets content has been registered.

Try tab first, and then enter? (Can’t remember if tab is standard way of moving out of gadgets so might not work.)

@kas1e

Now, Im just guessing obviously. But I found this link, glgeterror not resesseting its flag, that says that "glGetError should always be called in a loop, until it returns GL_NO_ERROR".

Could it be that glGetError (line 156 testherader.c) doesn't clear all flags, but calling printf and delay does (since tehy succeed)? Perhaps just check what glGetErrors returns, and possibly wrap it in a loop?


Or something?

@kas1e
Quote:
I think I read it all. And I didn’t ask to add a printf, but the sdl error print. But perhaps that does the same thing. Just wanted to find out if the first shader in the loop failed or the last.

@kas1e

Do you know which shader fails? Just add an SDL log error whenever a shader is compiled and you should see… 4 of them, I guess from looking at the code linked.

Something like this: