Most Excellent news!

Hats off to all involved.

LyleHaze

@LyleHaze

OK, replying to myself, something my therapist is asking me to avoid..

A most bizzare occurrence.
Since the re-installation of my system onto a spare HD, I have had a problem with SimpleMail ignoring cursor keys and linefeeds.
But Wait! I can hear you say. This is a thread about IBrowse crashing on exit. Read on, as the plot thickens.

Yesterday I was reading the docs on TextEditor.mcc, which I suspect may be the root of the SimpleMail problem. When I opened the MUI prefs for it, it complained about some sort of key bindings mismatch. I did my best to fix it, but my SimpleMail is still not working.
HOWEVER.. IBrowse no longer throws a recoverable alert on exit. (See, I told you I'd get there eventually)

Wonder of wonders, and I have no clue why. But the only thing I changed was TextEdit settings.

Or perhaps it was all just a dream.. you never know, really.

I hope this helps someone out there. Now if I could just get SimpleMail to see my linefeeds, I'd be as happy as a clam.

LyleHaze

@Futaura

Well, at least I know it's not just me.
A quick visit to the IB dev page shows that IBrowse is not for sale, and there are no updates currently available.

I'll be patient, but I really hope we're not waiting for the legal issues to settle, as that might a long time..

At some future time when a fix is available, perhaps you might post back to this thread so Sundown and I will know it's available?

Thanks,
LyleHaze

I'm running a micro AOne with the latest public updates.
I was frustrated with IBrowse giving "Recoverable Alerts" every time it shuts down. I finally got mad enough to wipe everything clean. New battery, new power supply, cleaned and checked all fans, everything great.
I did a clean install of OS4 and updates, everything stayed stable. For a day or two it seemed quite solid. Then I added "SimpleMail", including a half-dozen MUI classes to get it running.
The problem seemed to come back after those classes were installed. Everything works fine, but when I close IBrowse, AFTER the "cleaning up the cache" window closes, I get a recoverable alert, click mouse to continue.

Does this ring a bell for anyone? I can't believe I'm the only one that has found this problem. The most maddening part is that this is the ONLY bug I've found, but it comes up often enough to be a pain.

Suggestions are welcomed!

Thanks,
LyleHaze

[edit] ERROR 01000009 Task: 0x6CEC1AF0

that task is "IBrowse"

@Thread

OK, a quick check before I am off to work..

4.OS4:> version sys:kickstart/elf.library.kmod
elf.library 52.1

I think that's the problem.
I wonder if I've screwed up any other kickstart modules, too?

I'll try fixing this after work today.
Thanks to both for your help! I'll report back
when I get better news.

Lyle

OK, so I'd like to try OWB, and the first time I couldn't get it to open. So I have loaded it up again, this time also installing the necessary stuff into sys:sobjs as instructed.
Just like the last time, it will not run.
If I start it from a shell, I get a popup requester from ELF.library stating "unknown/unsupported reloc" and the command line error is "owb:file is not executable".
Since I seem to be the only one with this problem, I'm guessing I have hosed up something about my install,but I'm hoping I won't have to wipe SYS: and re do it from scratch. (that sounds too much like windows for me!)

I'm on a micro-C with the July update, it should be pretty close to "stock", but I have done some thrashing when I've looked for other problems before.

Suggestions are welcomed!

Thanks,
Lyle

@AlexC

I'm using a marrick LynX-10 interface on my micro-AOne.
I have not ported the drivers over yet, but it's easy enough to write scripts that work.

Lyle

@rwo

Sorry for the late reply..
I have been too busy to work on the FTDI driver.
If you have one in the works, you're way ahead of me.

Good to see progress !!

Lyle

OK, so after keeping my old cell phone for over four years, I finally upgraded to a new Samsung "Juke" phone. It's small, has all the basic features I need, and also includes an MP3 player.
I read the "Verizon" instructions and I see that to get music into the phone, I have to load Verizon software on my PC, then buy all my music from them.. Not nice.
I read the book that comes with the phone and I see in fine print that I can also just plug in and use Windows Media Player 10. I try it at work, it sees the phone, but I'm not figuring out how to get any music into it.
So I get it back home and just for fun, I plug the cable into my AmigaOne. Now we're making progress. I drag and drop a dozen albums from my MP3 drawer and all of them play just great. Mission Accomplished!
Yes, I know, I'm sure it can be done from a PC as well, but it's nice to know that I can use Amiga tools to rip and encode MP3 files, then move them to my new phone. It works much easier than the software that Verizon expects me to use.
Now if I can just figure out how to download my own ringtones..

LyleHaze

@Swoop

I understand your confusion.
I, too, am confused.

I could be wrong, but as I understand it, the "Assign"
command and the "path" command are different in purpose.

"Assign" allows you to assign a device name (ending in a colon) to a directory. Great for getting organized, great
for naming a point so programs can find it ("SDK:"), also great for copying the contents of a floppy onto a HD, as mentioned before.
But as far as I know, it has nothing to do with the search path for commands, unless your icon or command line is calling with the included device name and path. ("SDK:include_h/amiga_compiler.h")

I just read the "AmigaDos" book.. It seems to agree.
"Assign" is cool, and allows multiple assigns and tests and such, but it does not appear to affect the path.

If I'm wrong, please teach me more. I'm always ready to learn.

LyleHaze

@Raziel

OK.. At least we know DG is not creating an unexpected output cluster.. or it would have shown up.

And you know how to use ShowKeys to "test" a cluster for MIDI traffic (note messages, at least)

I don't know why DG is giving you troubles, as it works well here. Maybe you need reqtools.library? I know that earlier versions needed it, I do not know if that requirement was later removed.

Glad your MT is playing though. That's good news.

LyleHaze

@Raziel

You should see something on Showkeys, even if MIDI OUT isn't working..

What program are you playing MIDI with? Horny? DG_MidiPlayer? Something else?

Try This:
Open ShowKeys, then click on "Source" and tell me what your choices are.. That's a good starting point.

Better yet.. If you don't know where "DG_Midi" is sending it's output, try reading your choices from ShowKeys WHILE DG is playing.. You may see an "extra" cluster being created by DG.. Maybe..

Or, if you're a shell kind of guy, try "ShowClusters" for a list of all current clusters. Did I release ShowClusters yet? I'm not sure.

Lyle

@Raziel

Yes, I saw it.

No, I have not installed the Scumm software or developers files on my Amiga yet.

Yes, I may do so at some future time, but it will be after some other projects that I am already working on.

Any more questions?

LyleHaze

@Ferry

The classic Amigas could do MIDI over serial ports.. this is not workable on the A1.
The gameport (joystick port) of the A1 can do MIDI OUT only(via 686). If you have a soundblaster with a joystick port you can use that for one MIDI IN and one MIDI OUT (emu 10KX driver). There are some sound cards whose Joyport MIDI can work with the envy24HT driver...
All the above connect with a joystick to MIDI cable commonly called "MPU401 compatible".

The other option, IF your A1 has working USB, is to use the USB driver for _compatible_ MIDI interfaces. There is a list and pointer to the support website with the USBMIDI.lha driver. This allows _MANY_ MIDI devices to be connected at once. (I am currently running about 10 MIDI OUT ports, and about nine MIDI IN, each with sixteen channels)

All these are available on OS4Depot.. Just search CAMD and they'll all pop up. The documents with each are pretty complete, I hope.

LyleHaze

@Raziel

OK, getting you going..
It can be a bit tricky testing your connection, especially if you don't know if the problem is software or hardware, or the MIDI interface.. So here's the easiest way to figure it out.
1> Install your via686 driver into devs:midi (you already did this, I think)
2>Turn OFF the power, then connect the MIDI interface cable to the joystick port. Power back ON and boot up.
3> Connect the MIDI OUT cable from your interface to MIDI IN on the back of the MT32.
4>connect audio cables from the MT32 to an amp and speakers, or connect some headphones.
5>Run the "ShowKeys" program, and set the link to via686.out.0. It should already be in the list of available links.
6> Set showkeys to "All Channels"
7> Open DG_MIDI_Player, set the output to via.686.out.0 also.
8> Load and play a MIDI file from DG_MIDI_Player.

If you see ShowKeys flashing the notes, then you know that the software is working well, and the MIDI should be coming out the MIDI OUT cable.

If you hear music, you'll know that everything is working.

Showkeys is handy for "seeing" the music being played. It can also be used for testing midi inputs (but not on a via686 hookup)

re:Adding support to SCUMM.. I looked over the source. It looks like it won't be too hard to do, but I have no clue how to test it. Does SCUMM come with any apps that I can use to check for MIDI support? So far I only Downloaded the source archive.

Another option is for me to write the code and then pass it on to a SCUMM developer, but they would need MIDI gear, or Showkeys.

Lyle

@Raziel

Yes, that is correct.
If it doesn't open CAMD, then CAMD won't work with it.

Exception: In the early days of CAMD there was only "in.0" and "out.0", both from the builtin serial port.

If the program tries to open camd.library and will only connect to "out.0", then yes, you CAN use OS4 camd.. You only have to use the "MidiThru" shell command like this:

midithru out.0 via686.out.0

That command will "create" out.0 and feed everything coming into it to via686.out.0

All of this assumes that your scummVM program is opening camd.library..

Let us know how it works! (or IF it works)

Lyle

@Raziel

@Raziel

Please dont!

The MIDIPrefs is no longer used or needed. It was phased
out with the port to OS4.

Each program that uses CAMD is supposed to save it's own
setting and go back there when reopened.

Some of my CAMD tools just use a tooltype in the icon.
Some don't use anything (even if they should).

All the midi drivers in devs:MIDI will be opened when CAMD
is first opened, so you will have access to all your different toys.

Thre is also a USB MIDI driver that installs as a USB driver, but will still show up in CAMD cluster requesters.

Reminder: the via686 driver is OUT only. You can get MIDI IN working by adding a soundblaster card, or by using one or more class-compatible USB MIDI interfaces. I've had success with all of these (even all at once!)

Finally, some developers are hard-coding their programs to require the word "in" or "out" in the cluster name. This is a mistake. Clusters can be created by the user at any time, and can have any name.

As an example, I have a BCR2000 control deck connected to a MIDI controlled mixing board. All the links between them get complicated, and it's harder to add other applications. So I have it all sorted through a cluster called "Mix".

Some of the current MIDI applications will NOT connect to a cluster called "Mix", they either won't let me enter the name, or they change it to "mix.out.0" (which is useless)

This was covered pretty well in the original CAMD documents. The file "camd.intro", section titled "Establishing Links"

Sorry about the rant. Let us know when you get the MT32
playing music!

Lyle

@sundown

Sounds interesting.
Are documents on this available?

I vaguely recall the kickmodules always coming from the first available source, and then "selecting" a boot source from there.
Obviously I'm wrong, I'd like to learn more.

Hmm, Maybe "Lickstart" is how to boot an A1 with a weak battery... Might have to give that a try.

(completely off topic)
What I'd really like to know is how to get all the untested, not-working video modes out of my system.
Most or all of the "fakenative" modes are "stretched" so wide that the left half fills my entire screen.
How can I fix or remove these "bad" screenmodes?
/rant off

Thanks for the help,
Lyle

@sundown

Thanks.
I might change it later, but I want to complete testing first to determine which kick module is affected by this problem.
Funny that my machine has been rock solid since I got it, and suddenly there are new issues..

I am focusing on the kickstart modules because the first lockup, and a fair few since then, have been immediately after loading those up.

I hope to get time this weekend to:
Remove my main hard drives
replace my "test drive"
Put the older battery back in.
swap kick modules individually until the culprit is found.

brand-new open circuit voltage on a CR2032 is 3.25, according to datasheet and my meter.
"working" voltage is 3, so yes, 3.06 should work properly, and indeed does with the December release.

I'll take the time to do the tests. I can only hope that someone is willing to do something with the results.

I'm also hoping that doing a "Mix & Match" with the lickstart modules doesn't cause too many problems, but I guess I'll find out as I go along.

Hmm, "lickstart"?? Must be a typo.

I'll report results here after the weekend, if I get the chance to do it.

LyleHaze

@sundown

Sure, of course!
The old battery that I removed was at 3.06 volts.

I also understand the desire to divide the hardware and software groups. Sometimes it's hard to see the connections between them.

The reason that I took the extra time to install a spare drive and repeat the entire test was to determine the root cause of an apparent problem. I did not find what I expected, but I was able to find that the "problem" can be reliably switched on or off by my choice of which versions of kick modules I loaded.

And no, my machine is still not as stable as it was before the "upgrade". I still get occasional lockups, though not as often as before I changed the battery.

Yes, I'll be going back to the pre-july release.

It is apparent to me that many folks here have trouble with the possibility that a software update can affect the hardware that it runs on. Of course it can! Even something as simple as insufficient bypass capacitors can have a profound effect on the results of digital logic operations. If you don't believe me, try building without them and see how reliable your circuits perform. Clock them slow enough, all is well. Go a little faster, and the random element comes in.

I design electronics, and I write software. Possibly because I know both sides I am less likely to see an impenetrable barrier between them. I can easily design an SRAM device that works properly at lower data rates, but fails miserably when clocked more rapidly. Many would think that since the SRAM is "only" memory, that it's failures would be limited to providing wrong data. Not true. A low-power situation could cause it to latch data onto the bus too slowly, or fail to release the bus at the end of the access cycle. Such a problem could appear as random lockups, even while executing unrelated code.

If this problem was nothing more than me being too cheap to replace a battery, then yes, this would all be a waste of time. But consider this if you would: This is the type of problem that can stay hidden, and cause random crashes for no apparent reason. And it can be an absolute BEAR to track down, since the problem is not in the code that is executing at the time of the failure. Fixing this "little" problem would almost certainly take out some "undefined random" failures along with it. That's why I believe the information I'm providing is useful.

I took the time to dis-assemble my system and revert to the pure, native Dec06 release, and run it long enough to establish that it is stable, without lockups. Then, by ONLY adding the July release, the lockup problem returned immediately. The test was repeated to make sure it wasn't a coincedence, because I understand the need for proof.

I actually did that to figure out which "added software" was causing the conflict. When I realized that it was all happening within the original releases, I thought it worth reporting.

Yes, a low battery is a hardware problem. No argument.

But if installing and removing the July update can turn a lockup problem on and off like a lightswitch, I think it deserves further investigation. It's an opportunity to make the OS more reliable. I'd call that worthwhile.

I saved the battery. Please come on by and I'll demonstrate it for you personally.

LyleHaze