@mechanic

Yes, we must add the clock frequency in the xn file, or else it will make bad assumptions.

.xn files are short, I have pasted one below.

If memory serves the name given must match the filename exactly..
A-EON_Xena Device

///////////////////File begins AFTER this line///////////////////////////////
<?xml version="1.0" encoding="UTF-8"?>
<Network xmlns="http://www.xmos.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.xmos.com http://www.xmos.com">
<Type>Device</Type>
<Name>A-EON_Xena Device</Name>

<Declarations>
<Declaration>tileref tile[2]</Declaration>
</Declarations>

<Packages>
<Package ID="0" Type="XS1-LnA-128-QF124">
<Nodes>
<Node Id="0" InPackageId="0" Type="XS1-L8A-64" SystemFrequency="500MHz">
<Tile Number="0" Reference="tile[0]"/>
</Node>
<Node Id="1" InPackageId="1" Type="XS1-L8A-64" SystemFrequency="500MHz">
<Tile Number="0" Reference="tile[1]"/>
</Node>
</Nodes>
</Package>
</Packages>

<Links>
<Link Encoding="5wire" Delays="0,1">
<LinkEndpoint NodeId="0" Link="XLG"/>
<LinkEndpoint NodeId="1" Link="XLF"/>
</Link>
<Link Encoding="5wire" Delays="0,1">
<LinkEndpoint NodeId="0" Link="XLH"/>
<LinkEndpoint NodeId="1" Link="XLE"/>
</Link>
<Link Encoding="5wire" Delays="0,1">
<LinkEndpoint NodeId="0" Link="XLE"/>
<LinkEndpoint NodeId="1" Link="XLH"/>
</Link>
<Link Encoding="5wire" Delays="0,1">
<LinkEndpoint NodeId="0" Link="XLF"/>
<LinkEndpoint NodeId="1" Link="XLG"/>
</Link>
</Links>

<JTAGChain>
<JTAGDevice NodeId="0"/>
<JTAGDevice NodeId="1"/>
</JTAGChain>

</Network>

@mechanic
Choosing between a wrench and screwdriver doesn't make sense if you only want to get hammered. :)

@broadblues
Thanks. Sentinel X-Logger has some potential, and I REALLY hope someone tries the X5000 extensions for additional speed. That would take the project beyond just eliminating the need for a second computer.

@thread
I have a few ideas occasionally. One that is more "Fun and Flashy" would be a driver for "NeoPixels". briefly, these are serial chains of individually addressed, full color RGB LEDs. Less wiring, more fun. But the signal format used is very quick, and NOT tolerant of delays. Even using a PIC or Arduino can be tricky if they must pause to support comms with the master...
The "unusual" ability of Xena to use any single port pin for very fast, well timed output is a natural match. and if someone was foolish enough to want a LOT LOT of Neopixels, multiple strands should be as easy as
running the same program in multiple threads.

Getting all that data from the Amiga to Xena for imaging would be much simpler if there was some dual port RAM between them, which the X5000 has.

Much could be done on an X1000, MORE could be done on an X5000
with NeoPixels.

It could make some REALLY "flashy" stuff to show off, and an ARexx port could make the display useful too.

Yes, just flashy lights.. but what could you make with them?

@tekmage

"Digital" mixer.. definitely do-able.
The Xena chip has no analog, but it can handle serial streams with amazing speed.
If the I/O for this digital mixer was S/PDIF optical, then it also is completely isolated electrically, which plays well into the "blow it all up" conversation as well.

The X-1000 has S/PDIF input AND output, one is just a header, but I'll bet it could be "activated" and populated fairly easily. so one channel of mix IN could be from AHI, and the final mix COULD be streamed, saved, further processed as well.

Quite interesting.

@MichaelMerkel

The software is working on an X1000. it is a combination of Amiga and Xena code that, when combined with some hardware, will capture and store Debug output on an SD card mounted on the Xorro card.

It "closes" the file on reboot, and then opens a new file on restart. Soft reboots continue the same file without interruption.

The files are saved as plain text, using a FAT file system on the SD card. The card MAY be removed and read, but it's far easier to just read the card from the Amiga command line. When retrieving a file, it is named by the date and time it was opened.

The "hardware" needed on the Xorro card is two circuits: A max3232 chip to create a serial port for Xena, and an SD card socket and card for file storage. Both of these circuits can also be re-used by other Xena projects when Sentinel is not running. Xena is quite versatile that way.

The Xena chip has no flash, she is RAM only. So after a hard reboot, the X-Logger software must be re-loaded before logging continues. The presence of the X-Logger code can be confirmed from the command line, and may be re-loaded from the command line as well. So it could be scripted easily.

My Xorro board, with the serial and SD ports, has been shipped back to AmigaKit. I _assume_ they want to be able to build the necessary parts for customers who request it. That is an assumption, and should be confirmed with them.

All the above information is the "current state" as best I can tell. But there is more to know if you're curious enough.

The XTools (command line tools for Xena) are being ported to the X5000. Not quite there yet. But I am confident they will be soon. I'm not the one doing the port, but I am quite excited to have some help with these.

The Xena design has been improved on the X5000. One of the improvements that I completely missed on my first inspection is the availability of program flash! Apparently it is possible to store a default program into flash, and have Xena load it on hard-boot, if enabled by jumper.

In the short term, it should allow running X-Logger automatically on power up. In a more developed state, it might even support more advanced software for multiple Xena task management.

Another improvement on the X5000 is the "Haze-Xorro" header. Using this, the MAX3232 serial chip is not needed to capture debug, and there is potential for significantly increasing the baud rate of the debug stream, which would reduce the "slow-down" of the system when debugging.

Jamie Kruger has begun a series of articles on Xena. I hope the details I have offered here will generate more interest in his writing. I can tell you he is doing lots of research, and working hard to get the facts as accurately as he can. His writing is a good read.

http://www.google.com/url?q=http%3A%2 ... mH8VQ_0dMyj283K0XqHyjE2nw

@cha05e90

Yeah. What Andy said. :)

To add a bit of detail, any "Cloud Print" ready printer would work. But also, any printer with a Windows driver could be reached through Chrome.

While the idea of having a windows machine act as a print server is not ideal, it does have a VERY wide fan-out.

GCP also works great with Android devices, so you can print easily whether you are at home or away, from your cell phone.

Another possibility that may have been overlooked, you can print easily to any GCP printer that has been shared with you. So it takes "remote printing" to any application that needs it.

But the part that gets me most enthusiastic is that this one driver could potentially reach ANY KIND of printer. and that kind of flexibility is a good thing to support.

Just my thoughts, worth all that you paid for them :)

Excellent!!

This looks like a great bridge to more modern printing.

I have a color laserjet now I'll need to set up one of the winblows machines as a Google print server.

If I can help, just mail my usual nickname at gmail.com

@AmiKit

I'm not sure what you are asking for.

You said the "Startup" drawer is not there. We use sys:prefs/wbstartup instead of the startup drawer.

But that will run after EVERY startup.

If you want to run once, after the OS is installed, that would be called from the same script that called the OS installer.

Perhaps my own experience is not as broad as some others, but I found IDLTool a VERY helpful program.
I was maintaining camd.library, which was based on code from AROS. While debugging and adding a few missing features, I kept the source AROS buildable so that all improvements could be fed back to them. After all the bugs were worked out and we had enjoyed enough time to consider it "stable", I decided to finally make it OS4 native.
IDLTool was exactly what I needed to create the skeleton, properly formatted and with all the various header files included. Once I had a handle on it the port almost wrote itself. As a result camd.library lost a bit more than 35% of it's file size. Probably a bit more efficient as well, though I made no benchmarks to test it.

I am now writing a new library from scratch, and again IDLTool gave me a solid start, handling all the "ugly stuff" and letting me get right into writing library functions.

I guess it depends on what you expect. IDLTool is not a GUI. But it IS very good at weaving the web of various headers and libinit stuff into a tested foundation for new libraries (or devices, for that matter).

Just my own opinion, which might be worth nothing. :)

@gregthecanuck

What's a "win32"??

Is it classic, or NG?
:)

Interesting..
Timi is a very cut-up and re-arranged version of Timidity. Most of the Timidity ports for Amiga will either play a MIDI file or convert one to an audio format, what I needed was something that would play "live" so it could be used as a synthesizer in real-time.

To get back to your question.. Assuming DosBox runs under AmigaOS without killing other processes, all you'd need is a way to get the MIDI output stream from DosBox in to CAMD.. from there Timi or a real synth could take it and play it. (or record it, or display it, or whatever).

If somebody could give me a handle on that MIDI stream, attaching it to CAMD would be a very simple modification.

LyleHaze

Radeon R9 280X
Works great, keeps my feet warm too.

@AmigOS

I expect "Clone" might require identical drive geometry. Thjat's not going to happen.

I can't help with WinmUAE etc.. Out of my experience circle.

Good Luck!

Yes, this thread has been inactive for a year, but I bring very happy news: The Yamaha P45B Digital Piano is fully compatible. :)
Now that camd.library and camdmidi is distributed with the OS, there is NOTHING you need to prepare. Just plug this fine digital piano into your USB port and it appears as "Digital Piano.in.0" and "Digital Piano.out.0"
I am told the slightly higher end P115 is also fully compliant.

Now off to tickle those ivories. :)

@AmigOS

Sounds like fun!
I'll try to offer a small bit of help. HOPEFULLY it will come across as helpful and NOT as grumpy. I am old enough (and tired enough) that anything is possible. :)

While you gave an excellent description of what you intend to do, you were not terribly clear on what you need help with. Have you worked with SCSI before? If not, I can offer a few "generic" tips.

SCSI can support up to eight devices on a single interface. Each device requires a UNIQUE ID. No two devices can have the same id.. NOTE: The adapter itself is one of those devices, and will "consume" one ID.
IDs are often set with DIP switches.

The SCSI devices are chained together, and it is suggested/required that there is a terminating resistor at each end of the chain. Some devices (possibly your adaptor) have a resistor block that can be put in or taken out.

The 3000 has built in SCSI interface, I am not terribly familiar with it.
There are more than one "standard" pinouts for SCSI cables. pin/wire count is different between them.

Given the cost of SD Cards, it would be more than wise to get a few, and set aside "backup" boot disks, perhaps one as a clean install of the OS only, and another as a backup of your fully configured system.

SD cards are cheap, having backups of your machine are priceless.

Have Fun!

Yes, I try to stay in touch with A-Eon, as well as occasionally IRC'ing with AmigaOS betas and developers.

These past months I have been unable to work on Amiga things, but I am starting up again now, slowly.
If I can help anyone get a better connection to CAMD, I am usually happy to help. Maybe I should put together some example code that includes reading the MidiPorts prefs settings.

I always thought the two biggest obstacles to making music on the Amiga were the lack of MIDI support in the default install, and lack of a decent software synth. I am really happy that these are now on every F.E. install CD. Now that everyone has the support stuff, we might see more music related programs and tools.

@densho

I have no knowledge of how this project is being done, but I would _think_ that MIDI would be handled by CAMD, at least on the OS4 version.

CAMD is now provided as part of the OS, so is already installed in every system from F.E. onward.

All AmigaOS systems from F.E. onward also have a complete software synthesizer in the contrib drawer.

With this combination _any_ music software may assume the system can support MIDI, whether playing files or providing a "live" instrument.

Just my opinion of course, and I may be slightly biased. :)

@xenic

I was compensated for my work on the X1000 audio. It was also during a time that I was unemployed, and I must say the income was quite dear to me. I used it for "fancy things" like medicine and car tires. I was also the third or fourth programmer to work on it, so technically I didn't write the driver, I just tore it apart and beat it with a baseball bat until it made noise. Our S/PDIF output works, but we do not support proprietary codecs, probably because of the costs involved in licensing them.


But maybe a different perspective: If someone decided they wanted to build a new, high end Amiga system, let's consider some of the choices to make:

a: Let's build it using ONLY parts and chips that we already have drivers for, and we will get a machine that is literally made of lots of stuff we already had..

b: Let's build it for the future, and add stuff that goes beyond what we already had. HDAudio, dual cores, enough slots to support more/modern memory.

Which one is leading us into the future?

I'm just saying, designing a new board is a big challenge. Then getting drivers written for every little difference is another challenge entirely.

I suppose there's room on both sides of the argument. Those who still use "classic" Amigas know exactly what they have and what they can do with it, and that's wonderful. I have a huge respect for the classic Amiga, both hardware and OS. It began the revolution.

But it's hard to build a future there unless we find someone to start reproducing Agnus, Denise, and the other custom chips. And I suspect 68k series chips may be getting hard to find too.

So if we are to have a future, we will need to change, we will need to grow. With such a small community and limited cash resources, growth will happen slower than we want. And because we are made up mostly of people who are very passionate about "what is an Amiga?", there will be different ideas, different opinions, and different paths into the future.

One example of that is the variety of operating systems that have been designed to resemble the classic Amiga.. Either PPC, x86, 68k, emulated, or even run on an ARM core. For such a small group, we are quite diverse in our opinions.

So I'll be grateful for progress, at whatever rate it proceeds. And I'll contribute if I can, when I can, and be content that I helped to keep my favorite OS moving towards tomorrow.

Peace Friend.

@ddni

My delivery wasn't in August, but I agree with much with your original post.
The machine is just plain fun to play with!

I'm sure that the experience is different for each of us. Personally I don't do much with games. For the first couple years I was completely consumed with the compiler, and a long list of projects.. Some for myself, some for others, some just for personal education.

Lately, my "real world" job has simply taken over. No time to code, no time for socializing, and when I get a chance to sit in front of the X1000, I mostly wish I had more than fifteen minutes at a go. But last week I opened up Score, and had an absolute blast. I start playing, and switching back and forth between hard and soft synths, and I start feeling creative again. But for me Amiga has always meant MIDI. :)

As far as the missing parts go, I may have a different view. AmigaOS 4.2 has not released, but the OS has continued to grow and mature anyway. To put it simply, I don't care what they call it, as long as it's still progressing. I had a "go" at that network driver, and it almost drove me loopy. (A short trip, some might say). After that experience, I am perfectly happy running a network card and never thinking about that code again.

And the other core? The one core that IS running on my X1000 is working quite well really. If the other one joins in one day all the better, but I'm not losing any sleep waiting for it. My X out-runs all my previous Amigas by a wide margin, even with one core tied behind it's back.

And it's even more amazing when you realize that we're not done yet. The OS is maturing, there is new hardware being made, and despite a few snags along the way, it's still the computer for the creative mind.

I'm beginning to sound like a commercial.. I'd best stop here.

Have Fun!

@zzd10h

Wow, that's a lot of games.

The total list of all games on my X1000:
"Soliton", "Megaball"
And that's two more than I have on my micro.

I guess I'm not getting the full experience. ;)

Impressive graphics though.

Congratulations to Hans and the team, I know a lot of people have been waiting/hoping to get warped in hardware.

Lyle

I have a similar message when my HDAUDIO sound driver is not loaded.
Under normal circumstances:
A›HI reads all the files in devs:audiomodes, and tries to find and start each device listed.. One of those is HDAUDIO, which will load and run devs:AHI/hdaudio.audio.
If all of those things happen, then NemoSound should be able to find the hdaudio driver and attach itself there.
When I am running certain tests, I have to remove the HDAUDIO modefile, and AHI does not load/create/enable the HDAudio hardware.. and that's when I usually see this error.

Or it could be missing the DONOTWAIT tooltype.

Happy April 1.
:)