Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: my_pc_is_amiga on February 16, 2019, 06:17:54 AM
-
I have 3.1.4 installed on an A4000T and have tried both the DMusic program and DMPlayer to play some saved deluxe music songs. In both cases, the song may play for a few seconds and then gets into some infinite loop (and Amiga hangs).
Multiview, EaglePlayer, and some other programs that uses the amiga audio are working okay.
-
Hi,
I tested in an A1200 and in an emulated A4000T, and in both cases all included example scores played perfectly well till the very end. I used both the program and the player.
I obtained the disks from here:
https://www.exotica.org.uk/mirrors/ami_sector_one/deluxemusic.htm
I am unable to reproduce your issues.
-
Thanks for checking I’m baffled though I did get cleophia song to work but the others not working for me
-
is playback set for internal audio or via CAMD?
-
This is for playback of the amiga internal audio. I did some more testing:
1) A3000 with 030 -- works fine.
2) A4000T with 040 -- applying "nofastmem" works fine.
Started to suspect something was bad in my fast mem...so I started to pull some fast memory out but still saw same issue and then I tried
c:cpu NODATACACHE -- works!
Does the 3.1.4 ROM itself set the CPU differently then it did in the past (i.e. in 3.1)?
-
Then, you should first check that you have a properly working and updated 68040.library.
I highly suggest that you use the MMULibs (Aminet).
-
Yeah, when you install ThoROS, you need to collect all the missing pieces from Aminet yourself.
-
Yeah, when you install ThoROS, you need to collect all the missing pieces from Aminet yourself.
Kolla, what exactly is your problem? First, this is AmigaOs, has ever been. Consider we would have delivered freeware (as for example mine) components (as opposed to Amiga components) with the operating system? What would you then complain about? Here is my pick:
Now you have to pay for components you find in the Aminet, and Hyperion takes hand on freeware software and sells them as their software.
This worthless stuff does not work on Phase 5 cards.
So, how exactly can one do right "for you" so you do not complain, once in your live?
-
Not my type of spelling or words of choice, so no.
I am "complaining" (actually, I am surprised) that OS 3.1.4 doesn't support standard, stock CBM hardware out of the box. This release was supposed to minimize the need for third party downloads, but instead it enforces it.
-
Then, you should first check that you have a properly working and updated 68040.library.
I highly suggest that you use the MMULibs (Aminet).
Thanks -- I had actually tried 2 ways. I have a A3640 board on the A4000T and so I used the CBM 68040 library that came with the original 3.1 install disks (mmulib not installed). And then I tried the 68040.library from mmulib with mmu.library and 680x0.library. Both ways I get some kind of crash (when DATACACHE enabled).
-
@kolla
I am "complaining" (actually, I am surprised) that OS 3.1.4 doesn't support standard, stock CBM hardware out of the box. This release was supposed to minimize the need for third party downloads, but instead it enforces it.
The audio side things has proven to be less than ideal for programs that don't follow official C= references. There was an issue with MIDI instruments functionality messing up on ADoom (now fixed) but obsolete programs will not be patched sadly. Maybe OS3.1.4 should have taken an approach of tidying up the code whilst compromising and "supporting" the best bugs as utilised by programmers under previous versions of the OS! ;)
I personally don't have a problem with third party patches, programs or hacks as long as my programs work as intended. It's not as if OS3.x will be developed into the next millenia or requires tidying up for the world of quantum computing or something! ::)
-
Not my type of spelling or words of choice, so no.
I am "complaining" (actually, I am surprised) that OS 3.1.4 doesn't support standard, stock CBM hardware out of the box.
Because installing the wrong 68040.library on some third-party Turboboards would rather damage the system than being helpful. You know that of course. I am all for a "standard 68040.library that works on all boards", but this is wishful thinking.
-
Concerning the bug in the doom library, there will (already is) a workaround for it. It is not that I "don't care", I just prefer to have bugs fixed at their origin. As for this problem, it is too early to say. One thing that happened is that the audio.device was recompiled with SAS/C instead of lattice, and SAS/C does not only have a different register allocation (triggering the bug in the doom sound library), but it also optimizes better - which might be a problem with hardware register access.
-
As for this problem, it is too early to say. One thing that happened is that the audio.device was recompiled with SAS/C instead of lattice, and SAS/C does not only have a different register allocation (triggering the bug in the doom sound library), but it also optimizes better - which might be a problem with hardware register access.
The NODATACACHE option actually is not reliable -- I thought it was working but I was wrong :(
What has changed from my yesterday report is that I pulled my Denab card out and BigRam board out and kept the 16MB of fast memory. If there are any debug steps to help with this, please let me know.
-
Because installing the wrong 68040.library on some third-party Turboboards would rather damage the system than being helpful.
I never heard of 68040.library actually damaging systems. And this was not "some third-party" board, but plain 3640 boards, as found in stock commodore A4000 systems. I find it odd to not provide the 68040.library for this, as 3.1 did. It makes it less than obvious what library should be used.
-
I never heard of 68040.library actually damaging systems.
Then you learn something new. The CBM 68040.library does not work on some P5 boards, and - as their DMA layer is delicate - may corrupt data upon transport, or may hang or crash during use, for example if some P5-only graphics cards are connected to the board that are not visible to the system due to their lack of supporting autoconf.There are a couple of additional boards that have "vendor specific" extensions in their library, or use a non-standard setup.
It makes it less than obvious what library should be used.
It is *very* obvious. Always use the library that came with the board. If the board was a CBM board, it came with the CBM library. It is really *that* simple.
-
It makes it less than obvious what library should be used.
It is *very* obvious. Always use the library that came with the board. If the board was a CBM board, it came with the CBM library. It is really *that* simple.
So OS 3.0 68040.library it is, I'm sure it is optimal.
No board ever came with MuLibs.
-
So OS 3.0 68040.library it is, I'm sure it is optimal.
Good enough to keep your board working. If you want to tweak, that is up to you.
No board ever came with MuLibs.
Wrong.
-
The audio side things has proven to be less than ideal for programs that don't follow official C= references. There was an issue with MIDI instruments functionality messing up on ADoom (now fixed) but obsolete programs will not be patched sadly. Maybe OS3.1.4 should have taken an approach of tidying up the code whilst compromising and "supporting" the best bugs as utilised by programmers under previous versions of the OS! ;)
Supporting bugs? I prefer programmers to do their job properly and follow correct C= guidelines. I do see your point however, and hopefully the amount of badly written software that actually breaks is tiny. ;D Thing is, no one is being forced to install 3.1.4 and the target audiance for 3.1.4 should be people who are 'looking ahead' more than 'looking back' IMHO.
-
Supporting bugs? I prefer programmers to do their job properly and follow correct C= guidelines.
Me, too. But what can we do? With every application Os 3.1.4 looses, a user is lost. It is a balance one has to find. In this particular case, it is eay to add a workaround (essentially, one line of C code), and the workaround does not hurt. In other cases, such workarounds are costly and not included. With every non-working application, we generate "bad press" because somebody will blame and complain and will argue that this Os is just an incompatible mess because his favourite program does not run anymore, without understanding that it is not the Os to blame, but a lazy author or an unwilling third party provider...
If you look at 3.1.4, there are other such "small compatibility patches". For example, SetPatch installs one into WaitIO() because some programs (erraneously) assume that WaitIO() returns a BOOL instead of a "struct IORequest *" and then deadlock, hang or crash.
In again other cases, software compatibility is lost because its authors made stupid choices and we cannot work around them in any practical way. Consider the Os 3.9 locale where for reasons unclear to me, H&P decided to assign new string IDs to their preferences system instead to stick to the ones 3.1 came with.
It is always a balance, and it is not easy to find the right balance.... After all, this is Amiga land, with Amiga users, that will blame you for whatever decision you make.
-
First off, we are very fortunate to still have very talented programmers for the Amiga and I want to thank Thomas and others involved for the AmigaOS3.1.4 update! This post was not meant to put any "bad press" but rather just to feedback and get help in case there was something that could be done.
Thomas, the workaround fix you mentioned, does that take care of the DeluxeMusic problem or was this for the doomslibrary? Or is it the same bad programming in both programs? Would be nice if more software could have their source code transferred or if Deluxe Music could get some revitalization? Wouldn't know how that could be done but SoftWood FinalWriter is an example though.
it is eay to add a workaround (essentially, one line of C code), and the workaround does not hurt. In other cases, such workarounds are costly and not included. With every non-working application, we generate "bad press" because somebody will blame and complain and will argue that this Os is just an incompatible mess because his favourite program does not run anymore, without understanding that it is not the Os to blame, but a lazy author or an unwilling third party provider...
-
@my_pc_is_amiga
First off, we are very fortunate to still have very talented programmers for the Amiga and I want to thank Thomas and others involved for the AmigaOS3.1.4 update!
Yes, that is true, but it would be a far better situation if we could donate direct to Thomas and Co's efforts rather than to buy this phoenix type product from Hyperion who get the developers to work for free! I'm unclear on the end game with the OS3.1.4 project (other than to save Hyperion's bacon) and think the OS4.x product line is a more convincing and long term way forward. I just feel stuck with OS3.9 on Classic hardware to be honest as we've put up with hacks for too long to progress past them without new software development on all the old applications we know and love.
A-EON have some IP and source code to revamp a few choice packages but will they back port to OS3.1.4? I'm not sure they will unless the Vampire V4 is mass produced and widely available.
-
Thomas, the workaround fix you mentioned, does that take care of the DeluxeMusic problem or was this for the doomslibrary? Or is it the same bad programming in both programs? Would be nice if more software could have their source code transferred or if Deluxe Music could get some revitalization? Wouldn't know how that could be done but SoftWood FinalWriter is an example though.
These two problems are unfortunately unrelated.
-
@Thomas Richter
Is the recent Cloanto acquisition of Amiga Inc trademarks affecting the 3.1.4 development? Is it possible for you and Olaf be contracted by Cloanto to merge 3.1.4 and Cloanto's workbench 3.x into a new de-facto standard Amiga Os 3 final edition for Amiga classics?
-
That may require some camel swallowing...
-
These two problems are unfortunately unrelated.
I have just recently noticed something else now which I've been seeing with several mod player/music programs (EdPlayer, EaglePlayer, OctaMed soundstudio). I only see this on my A4000T/040 and haven't seen it on the A3000 / 030 (both have 3.1.4 installed). While playing a song, I'm seeing my fast mem. depleting. I have not noticed anything on chip memory. And if I exit the program and do a avail flush the free mem. is not restored. So looks like there is some kind of memory leak but again have only been seeing this on the A4000T/040. I'd be happy to do any additional debug on this if there are any suggestions.
-
And if I exit the program and do a avail flush the free mem. is not restored. So looks like there is some kind of memory leak but again have only been seeing this on the A4000T/040. I'd be happy to do any additional debug on this if there are any suggestions.
These programs do not use the audio.device, they bang the hardware.
-
First off, we are very fortunate to still have very talented programmers for the Amiga and I want to thank Thomas and others involved for the AmigaOS3.1.4 update! This post was not meant to put any "bad press" but rather just to feedback and get help in case there was something that could be done.
Thomas, the workaround fix you mentioned, does that take care of the DeluxeMusic problem or was this for the doomslibrary? Or is it the same bad programming in both programs? Would be nice if more software could have their source code transferred or if Deluxe Music could get some revitalization? Wouldn't know how that could be done but SoftWood FinalWriter is an example though.
It's the same author who wrote Music-X... he's known as 'Talin':
https://medium.com/@dreamertalin/music-x-b4abc68d6f78 (https://medium.com/@dreamertalin/music-x-b4abc68d6f78)
-
So... 3.X.1.4? 8)
-
These programs do not use the audio.device, they bang the hardware.
I used SnoopDOS to find that audio.device is getting loaded by EaglePlayer and EdPlayer. I also used ROMSPLIT to extract the older audio.device 37.10 and then used LOADMODULE DOWNGRADE to load it. I tried 37.10 and then went back to 45.15 and for whatever reason, I haven't been able to reproduce this on 45.15 now. I'm totally mystified why I was seeing seeing it before.
-
These programs do not use the audio.device, they bang the hardware.
I used SnoopDOS to find that audio.device is getting loaded by EaglePlayer and EdPlayer. I also used ROMSPLIT to extract the older audio.device 37.10 and then used LOADMODULE DOWNGRADE to load it. I tried 37.10 and then went back to 45.15 and for whatever reason, I haven't been able to reproduce this on 45.15 now. I'm totally mystified why I was seeing seeing it before.
Yes, these programs open the audio device, but only to reserve channels. They then bang the hardware. They don't play through the audio.device.
-
As a Deluxe Music 2.0 user I ran into the same crashing issue.
I just wanted to add my observation.
I appears the crash when playing some of those "scores" that come with the program are happening because of the "instruments" assigned to the stave. Some of the included "scores" do not crash and they use different "instruments". The offending instruments are banging the hardware in a way that is a problem I assume.
Two solutions:
1) change the offending assigned instrument to another built in instrument that works.
2) assign Midi Instruments to the staves instead of built in Amiga sound instruments. If you have a Midi set up (which I do) this *seems* to fix any crashing and midi instruments through a synth will sound better than sampled Amiga instruments anyway.
-
As a Deluxe Music 2.0 user I ran into the same crashing issue.
Please get the free 3.1.4.1 update from the Hyperion webside. It comes with a new audio.device which fixes exactly this issue.