First: The way this shuts down without inhibiting drives is dangerous, and so I have to suggest never using this.

Second: I just got a copy of the Cyrus manual, and it appears this will work for that too. Maybe, untested.

BUT since Poff now works through acpi.resource, AND it offers a sync option, that seems a much safer way of doing things..

End Result: Cute hack but not a great idea, use proper tools instead!

Lyle

it seems that Poff works with the a1222, I had an older version.
and the sync option protects drives from shutdown during writes.. definitely useful.

so my little hack was fun, but there is a better way.

thanks all.

@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

Your comments on the delay make sense.
Even waiting five seconds is a poor substitute for actually inhibiting drive activity, then waiting for a proper response.

I originally ran it with no delay, and had to wait out a long validation on my next boot.

but it was wicked fast!

I'll look into a better way to verify that all disk io is completed.

Lyle

Oops, I missed a Quote.
Trying again:

echo "Power Off in two seconds"
Wait 2
echo >"SER1:BAUD=38400/CONTROL=8N1/UNIT=1" "#s"


That should work better.

I didn't see a forum for script kiddies. ;)

I have grown accustomed to remote power on and off for my X1000.
On by a small remote control mounted behind my monitor, and off by the "poff" shell command.

If I had a nickel for every time I've tried to "poff" the A1222, always getting "this model is not supported" or something like that.

So here's a little script to fix that. Just save this as s:shell/poff, then protect it with "protect s:shell/poff +s".

echo "Power Off in two seconds"
Wait 2
echo >SER1:BAUD=38400/CONTROL=8N1/UNIT=1" "#s"


That's it! Obviously you could snap it off immediately without the Wait, but I did manage to invalidate my SYS: once that way, so perhaps letting the bits settle for two seconds might be preferable.

Not a big deal, but it might be handy for someone.

LyleHaze

I am using a StarTech.com 40/44 to IDE to CompactFlash adapter, Amazon ASIN B0026OYEEQ IDE2CF.
With it I use a SanDisk 64GB Extreme Compact Flash card ASIN B00NUB2RPW

Here's what I found:
When attached to a 40/80 cable, and powered from a floppy drive connector, it works great at all PIO and DMA modes.
When attached to a 44 pin cable, and powered from the same 44 pin cable, the fastest DMA mode gets unreliable, but all others work well.

Of interest: The Compact Flash interface is IDE. Same pins, same pinout.
So, at least the higher end cards should work fine.
In this case available power seems to play a part.

Other Micro-AOne info:
The USB pinout for the front panel connectors is not quite normal, and the serial port pinout is a less common one also.

Details are available here: https://web.archive.org/web/2008102505 ... cscaug.us:80/ua1page1.htm

Like others, my experience with KVM's has been spotty.

I use a manual, mechanical HDMI switch to go between my X1000 and whatever secondary computer is up at the moment.

Audio is something I spend a lot of time working on, so I need a little extra there.
I have an audio mixer with 8 stereo inputs. My X1000, the television (I'm in the living room), a Pi MP3 player running "Rune Audio", two pairs from a 4 channel USB sound sampler, another pair from a Yamaha Synthesizer, and a pair of open jacks for whatever else is happening at the moment.

The mixer is remotely controlled by MIDI, so it's easy to control from a GUI or scripts as desired. I recently added an IR input that controls JUST the television volume, and it's trained to the Roku remote control.

The mixer is now 14 years old, and still works great. I was thinking about making more of them, perhaps a bit smaller than the rack mounted one I have now. I just can't imagine working without the ability to hear all the devices that I need to.

There are many possibilities, I can only guess which one(s) might apply.

The example uses "aifc". I usually use other formats, though 16 bit and 44100 should be fine. (note, newer USB based audio seems to default to 48000 instead of 44100)

The input you used was either microphone or line input, either of these can be overloaded by a headphone connection. I suggest trying lower volume levels on the source device. A "best possible" solution would be to use line level outputs to the blue connector. It would be SO MUCH EASIER if we had proper "VU Meters" for AHI inputs and outputs. (note, we DO have proper VU meters for X1000 and A1222 builtin audio. I've used them extensively for about a year now. They just haven't been distributed yet)

The method itself is solid. The noise is either a level problem (most likely) or a poor connection, or possibly a noisy source. The "device level" software is doing a simple copy, it's not adding or subtracting any noise.

Using "better software" might give better control or at least better visualization of the levels, but having to work through AHI makes everything a bit generic.

More keyboard details:
CFE requires the keyboard to be connected to a specific USB input.
Some "normal" USB keyboards, like my Rosewill cherry boards, will
stall CFE and prevent a boot sequence, if connected to the correct
USB socket.
By connecting to a different USB input, my keyboards work fine after booting, and I either leave the CFE keyboard input empty, or I put a different keyboard there just for CFE boot select usage.

It's not much more than a nuisance, except for the few times I plugged in to the wrong spot and the machine refused to boot at all. (brief moment of terror before I realized what was wrong)

And just to pile on: builtin audio works. ;)

assuming OS4, there's also a "barebones" method requiring no additional software.
please read sys:documentation/AHI/ahiusr.guide.
System Description, AHI Handler

To record directly from a sound card input:

Copy AUDIO:SECONDS/10/TYPE/AIFC/B/16/F/44100/C/2 sample.aifc

All the options are described in that document.
Actually, I'm not sure if it'll record from the sound card input or the sound card output, but I'm not thinking terribly well today.

in any case, it's a rather direct method.

Have Fun,
Lyle

"I've seen negativity, bitterness and zealotism (close to religious fanatism) when it comes to OS4."

I agree completely. I _try_ to bring understanding. Our greatest strength is the dedication of the community. It is also our greatest weakness, since we each have such strong opinions about what is best for the platform.

When I just can't take any more, I shut out the public. Coding on the Amiga is my personal activity. It doesn't require the input or opinions of others. I enjoyed coding before the "internet", I can still enjoy it now.

Let me congratulate you on the success of your driver. AHI is not an "easy" target, neither is Azalea. You have done VERY well. Thank You for your contributions.

I'm still coding, and working together with one or two other developers as needed. I am down to just one NG Amiga, as there are no repair facilities for my little Tabor. It's still an awesome OS, and a great pastime.

"Public Opinion" is neither in my control nor any of my concern. Those who make a hobby of complaining are free to do so, but not in my ear.

Maybe things will get better, maybe not. I'll keep on coding either way.

GREAT driver.. please consider staying with us, as your life and time will allow.

Lyle Hazelwood

I am no network Guru. I know almost enough to get by.
But I just found a neat trick to get a bit more out of my Amiga when online.

This might be related to the network stack, or Odyssey, or any other part of the OS, but I thought I'd put it here.

As our software gets older, there are more and more troubles getting things to work. In my own case I'm using OS4, but this likely applies to all the variants too.

GMail has been difficult, then impossible to use from my Amiga. I just keep getting demands to upgrade my browser, and it refuses to connect.

Recently I changed my home network, replacing my router with a "bridge" that picks up WiFi and creates a private wired network for my home. I did this on a raspberry Pi, and it works better than I had hoped.

And now my Amiga can get into GMail without issues!

Neat trick. I suppose for others just adding a Pi bridge into your Amiga case could make your Amiga WiFi capable as well as more usable with modern services. Considering the low price of a Pi, seems a good option.

I'm not aware of any issues with Alfred. My email is the same as the last time we spoke.
I would like to think I'm easy to reach, but its also true that I've been very busy with family issues, and I have had no time available for Amiga development for a while now.

There is nothing preventing Alfred from further development on his excellent Bars&pipes port. he's done amazing work so far and continued work is always good news.
From the source he generously shared with me, I did make some changes, especially to the way it links with CAMD. I also began a move towards scalable graphics, but that got too big rather quickly.
I never meant to take credit away from. him, and I thank you Trixie for pointing out the mentions shown.

As I finally finish up a commercial project I've been working on for way too long, I am already beginning new MIDI software (as well as older programs like Score).
Taking care of my wife is my top priority right now. there will be more, but it may take a long time to be released..
Alfred, if I have offended you in any way.. please let me know so I can try to make it right.

Wow.
I go away for a couple days of overtime, and it looks like I missed the party!

It's interesting that kas1e gets different compile issues. I didn't expect that.

I'm sure the CAMD cluster code can be improved. I am happy to do it, but finding enough time to do it might not be easy.

I have not even had time to play with it yet. I'm not sure when I will either. But it's always good to see MIDI activity on the Amiga. I'll try to keep an eye on this forum in case I can help, but there might be a couple days delay when I get busy at work.

This is all good news. :)
LyleHaze

@kas1e

Thank You

There aer quite a few GUI classes that are opened in oca.c but not declared in oca.h

I missed that.

Mine has been fixed, I can send it to you or you can fix it up from there.
Once oca.h is corrected, just include it in any source file needing gadget classes declared.


Thanks for that.
Actually I'm kinda surprised that the only problem was an omissioon in a header file. There was a LOT of fast editing going on, something was sure to get missed.

updated oca.h is below.

[edit] Button, Scroller, and Slider gadgets are all in the public release
SDK53.30 .. hopefully updating the oca.h file and including it as needed
will fix the problem.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// oca.h
#ifndef OCA_H
#define OCA_H

#include <proto/intuition.h>

#define MAJ_REV 53

// Libraries
extern struct AslIFace *IAsl;
extern struct DiskfontIFace *IDiskfont;
extern struct GraphicsIFace *IGraphics;
extern struct IconIFace *IIcon;
extern struct IntuitionIFace *IIntuition;
extern struct LocaleIFace *ILocale;
extern struct UtilityIFace *IUtility;
extern struct WorkbenchIFace *IWorkbench;

// Gadget Classes
extern struct ClassLibrary *BitmapBase;
extern Class *BitmapClass;

extern struct ClassLibrary *ButtonBase;
extern Class *ButtonClass;

extern struct ClassLibrary *CheckBoxBase;
extern Class *CheckBoxClass;
extern struct CheckBoxIFace *ICheckBox;

extern struct ClassLibrary *ChooserBase;
extern Class *ChooserClass;
extern struct ChooserIFace *IChooser;

extern struct ClassLibrary *ClickTabBase;
extern Class *ClickTabClass;
extern struct ClickTabIFace *IClickTab;

extern struct ClassLibrary *GetFileBase;
extern Class *GetFileClass;
extern struct GetFileIFace *IGetFile;

extern struct ClassLibrary *GetScreenModeBase;
extern Class *GetScreenModeClass;
extern struct GetScreenModeIFace *IGetScreenMode;

extern struct ClassLibrary *IntegerBase;
extern Class *IntegerClass;
extern struct IntegerIFace *IInteger;

extern struct ClassLibrary *LabelBase;
extern Class *LabelClass;

extern struct ClassLibrary *LayoutBase;
extern Class *LayoutClass;
extern struct LayoutIFace *ILayout;

extern struct ClassLibrary *ListBrowserBase;
extern Class *ListBrowserClass;
extern struct ListBrowserIFace *IListBrowser;

extern struct ClassLibrary *RadioButtonBase;
extern Class *RadioButtonClass;
extern struct RadioButtonIFace *IRadioButton;

extern struct ClassLibrary *ScrollerBase;
extern Class *ScrollerClass;
extern struct ScrollerIFace *IScroller;

extern struct ClassLibrary *SliderBase;
extern Class *SliderClass;
extern struct SliderIFace *ISlider;

extern struct ClassLibrary *SpaceBase;
extern Class *SpaceClass;

extern struct ClassLibrary *StringBase;
extern Class *StringClass;
extern struct StringIFace *IString;

extern struct ClassLibrary *WindowBase;
extern Class *WindowClass;
extern struct WindowIFace *IWindow;


//
// Opens all libraries, classes, devices
// reads all args and tooltypes
// returns RETURN_OK, else RETURN_FAIL
//
int32 openAll(int argc, char **argv);

// always safe to call, handles any intermediate states
// displays any given reason by errMessage()
// ALWAYS returns RETURN_FAIL
int32 closeAll(CONST_STRPTR reason);

// use any available output, or create one if needed
void errMessage(CONST_STRPTR reason);

// easy OpenLibrary & GetInterface in one
// no need to store LibraryBase, as long as closeInterface is used to cleanup
// displays error details by errMessage if needed
APTR openInterface (CONST_STRPTR lib_name, int32 lib_vers,
CONST_STRPTR int_name, int32 int_vers);
void closeInterface (APTR interface);

// IIntuition->OpenClass() with error text output
APTR openClass(CONST_STRPTR className, uint32 classVers, Class **classPtr);

#endif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HornyOS4Ver1.4_Source.readme:

This is the first edit of HornyOS4 since the release of source code.

So far, I have:
removed key requirement
fixed an unfreed signal
expanded CAMD cluster selection
Changed variable types to int/uint
removed #ifdef OS4 conditions
added library pointers
removed #libauto from makefile
added warnings to makefile
replaced deprecated functions
bumped version to 1.4
added a *.debug build to makefile

And likely more I have forgotten.

There is more to be done, but this is a good point to get it back into GIT.
I have not yet run the program much more than loading an SMF and playing it. But that seems to work well enough.


BIG thanks to Timo Kloss for releasing the code.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kas1e:
If you are willing to put these back into the GIT, please email lylehaze @gmail.com so I can reply with the source.

Thank You
LyleHaze

@trixie

There is no way to tell.

clusters are between programs.
they do more than just inputs and outputs.

example:
I have an audio mixer (hardware) in my studio. I control it from a bcr2000, and from a software mix window. and I have a master volume slider beside my keyboard.

a script on startup checks for which devices are connected, and each is connected to cluster "mix" as input AND output.

when I turn a physical knob on the bcr2000, the master volume changes in the mixer. the software mix window master slider also moves. the vmeter volume slider LEDs also move to reflect the change. everything stays in sync.

later I run a script that reconfigures all mixer channels. All the devices update in real time.

later I'm recording a tricky bit, and I want to automate it all. I record "mix" and it's all captured into a track of horny. later when I play it back, the mixer and all the controls come alive with the controls.

so, is cluster "mix" an input or an output? there's many sources and many listeners connected there.

at work.. I'll check in later

Lylehaze

@trixie

ClusterList.lha has been uploaded to OS4Depot.
I think it's in Drv:Misc/ like most of the CAMD stuff.

Source included, it's really quite simple.

LyleHaze

kas1e:
As soon as I have a working build I will either return it to GitHub or give it to someone to do that for me.

Right now I'm adding code for Library/Interface/Class opening and closing.

Then I'll track down the missing signal.

After that I'll "check it in" one way or another. There ARE more bugs, many are GUI related, and I suspect it's from the use of macros.
Removing them would be a BIG job.. likely more than I am willing to try.

Let's see how much I can get done tonight before I pass out.
Getting old is no fun at all. :)

Lyle

[edit].. Mad typing again tonight. LOVE the CherryMX Brown keyboard. :)
HornyOS4 now opens it's own libs and classes.
-lauto and -lraauto have been removed from the makefile.

It SEEMS to still open, though I have not done much with it yet.

Time to sleep, tomorrow I'll hunt down the hanging signal.

Lyle

[edit2]
Add at the end of
void EntferneCamd(void) {
(near Midi.c line 220)

if(-1 != playsig)
{
IExec->FreeSignal(playsig);
playsig = -1;
}

NOW maybe I can get some sleep.

[edit 3]
Compiles clean against -Wall