Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news about our project here

AmigAmp Minor Update 3.22page  1 2 3 

Gregthe Canuck

Posts 274
03 Jun 2017 03:47


Audio is an interesting subject.

Yes I believe in the long run an AHI driver will be needed, but it does come at an expense. Perhaps at some point an AMMX optimized version of AHI could be done?

The direct hardware-banging drivers are great for programs/developers with that ability as you will have the lower overhead for sure.

All hardware platforms in the long run end up going with some sort of audio abstraction layer. In the Amiga's case this means AHI. Sure there are pros and cons to AHI but perhaps in the long run some of AHI's cons could be mitigated.

Cheers!



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
03 Jun 2017 08:30


gregthe canuck wrote:

All hardware platforms in the long run end up going with some sort of audio abstraction layer.

This is an interesting topic to discuss.
AMIGA is in some way very special here.

Before the time of the AMIGA, we had those 8bit machines.
No one did use abstraction or OS to access the hardware on those machines.
We did always POKE on C64 the hardware fully directly.

AMIGA is in my opinion a very sexy combination.
a) AMIGA did provides a very advanced OS
b) AMIGA had a clean defined Chipset, and allowed always direct access to it.

So AMIGA gave both options to the developers - and allowed the programmer also to take full control of the machine.
I think this combination is what gave the AMIGA its spirit.




Gregthe Canuck

Posts 274
03 Jun 2017 09:24


The whole hardware abstraction thing happened on PCs and Macs mostly because they never came with any decent built-in audio. It was always an add-on and forced people to have to come up with a base abstraction API and matching drivers.
 
On Amiga the base audio was good but it started to fall behind, so cards like the Toccatta (which I own) came out which then needed custom drivers. Thus was born the need for an additional abstraction layer on Amiga and now we have AHI for all its good and bad points.
 
You are making a good point though, perhaps we just say "no, the built-in audio is good enough and could improve over time". "Don't waste your time with AHI/drivers.
 
The one challenge I see is mixing outputs from multiple programs. For example I have a music program running in the background which needs all 8 channels, but now I also have some other applications or games which need to generate sound from time to time. How would that be handled?
 
I am thinking it would be nice to have some sort of mixer support one layer above the hardware. Windows 7 did that with their audio support - there is per-application and per-system volume control.

Maybe this can all be handled by an updated audio.device? Maybe an AHI emulation driver could end up being basic stubs into an improved audio.device?

Maybe this is expecting too much? These are just some ideas/thoughts I am putting out for consideration.
 
Cheers!


Vojin Vidanovic

Posts 770
03 Jun 2017 10:41


Gunnar "So AMIGA gave both options to the developers - and allowed the programmer also to take full control of the machine.
I think this combination is what gave the AMIGA its spirit."

Agreed, so while keeping direct hit (slap :-) access tradition, AHI/MHI driver should be kept for the Amiga softwares sake.


Thierry Atheist

Posts 644
04 Jun 2017 13:26


Forget "AHI" and "RTG"!

(That's for the "competition". Like registry, swap files, log-ins (some have) mandatory registrations and -->add you own pet peeve<-- are too.)

Keep AMIGA video and audio "as is"....

Amiga, is the blueprint to follow...

VAMPIRE (Apollo Core) is it's unquestionable SUCCESSOR!!!!


Thierry Atheist

Posts 644
04 Jun 2017 13:35


AHI = 50 MHz of CPU power IN THE TOILET....

Do you REALLY want that, Vox?

PAMELA F.T.W.!!!!!!!!!


Cyber Gorf
(Needs Verification)
Posts 39/ 1
04 Jun 2017 17:47


Thierry Atheist wrote:

Forget "AHI" and "RTG"!

really?
without RTG every vampire sold until now would be quite useless: no saga video at all!

RTG (picasso/cgx) is nice - you can use it, but you don't have to!
same goes for AHI - you can use it, but no one forces you...


Cyber Gorf
(Needs Verification)
Posts 39/ 1
04 Jun 2017 17:52


Thierry Atheist wrote:

AHI = 50 MHz of CPU power IN THE TOILET....

You clearly did never use AHI.
AHI performs ok, for what is does. it's more like 0.5%-3% cpu usage on a 50Mhz 060.




Vojin Vidanovic

Posts 770
04 Jun 2017 19:12


Even IF due to bad drivers, bad AHI combination with 080 or whatever "there could be -50Mhz hit on Vampire" would use it.
       
        If it brings portability, and ablity to use e.g. mentioned apps like AmigaAmp and home studio, yes. On black Vampire x13+ ~90Mhz would tolerate it, on 110-500Mhz gladly. On 1Ghz ASIC no one would be able to tell the difference.
         
          I understand direct hitting as demo scene, Amiga gaming and app tricks bread and butter, but I also think such standards like MUI, RTG, W3D, AHI should be supported just for broader OS 3.x apps base and for programmers that wish to use that, as much simpler to code for.
         
          In other words you would have less proggies from past and in the future, if not supporting it in any form.
         
          Not that I think some newer solutions to problem shouldnt be invented. These were all stopgap solutions - AHI was brought to bring 16-bit sound to Classics. Once chipset goes Pamela cause is lost, but due to a lot software and hardware, dont leave it behind.If liked something about MorphOS and OS4 and even AROS where possible, was NOT leaving those behind.
       
        So like Gunnar sais:
       
        - Its GREAT to have direct hit back again
        - Its GOOD to keep the duality for apps and those who find it easier to programme for that layer
     
      and add a bit of spice
     
        - If BEST solution comes with AROS that would be best (e.g. MESA/Gallium on SAGA or 3D card on some mobo instead Warp3D - I see nVIDIA seems to be supported on AROS x64, if that could be transfered back to AROS 68k would enable SAGA 2D+nVIDIA 3D ond standalone/ASIC boards) that is more to standards of today, and yet not losing options 1) and 2)
 
  Some old AROS 3D article
  EXTERNAL LINK 
  On sound side of AROS I am glad AHI/CAMD exist. We just need Pamela driver :-)
  EXTERNAL LINK 
On mentioned subject of separate app and global sound control and mixing, that would be great either as vampire updated audio.device or as AROS 68k/OS 3.x AHI Pamela driver and mixer. Best both. If possible :-)


Johannes Schäfer

Posts 47
04 Jun 2017 22:24


Gunnar von Boehn wrote:

 
  This is an interesting topic to discuss.
  AMIGA is in some way very special here.
 
  Before the time of the AMIGA, we had those 8bit machines.
  No one did use abstraction or OS to access the hardware on those machines.
  We did always POKE on C64 the hardware fully directly.
 
  AMIGA is in my opinion a very sexy combination.
  a) AMIGA did provides a very advanced OS
  b) AMIGA had a clean defined Chipset, and allowed always direct access to it.
 
  So AMIGA gave both options to the developers - and allowed the programmer also to take full control of the machine.
  I think this combination is what gave the AMIGA its spirit.
 
 

Full qoute as fully agree!

Even although it is a little bit offtopic, also to mention:

Back on the 8bit machines, there only has been text based interaction with the computer.
Then with Apple Mac came graphical operation system.

Only Amiga had the combination of both simultaneously, graphical OS and shell in a window.

I think this is also a great combination from the AMIGA spirit.


Thierry Atheist

Posts 644
04 Jun 2017 22:27


If even ONE program that accesses Pamela directly is made, that's all that's needed! I'm talking about a music/audio playback program. Every game would have to access it "over and over again" by some method of their own devising.

Same goes with S-AGA custom video routines too. People using S-AGA are going to have the KILLER GAMES!!!!


Vojin Vidanovic

Posts 770
04 Jun 2017 23:14


Pamela direct access - I dont mind its abuse in killer games.
   
    I just need few AHI based apps. Like AmigaAmp and Audio Evolution, several HD recorders, editors. Unless you really believe one-in-all solution no one has ever made is possible - from simple audio editors, to advanced records or players?
   
    It would be enough that current 8-bit Paula AHI driver works but then we lose SAGA Pamela progress on AHI app side.
   
    Pamela 16-bit sound if it cannot be doone better, like in Wazp3d case with Warp3D, at least leave some support of Pamela to NallePuh updated that would enable "couple" AHI apps to work
    EXTERNAL LINK   
  Note: NallePuh uses mmu to as a hack that intercepts some custom chip register accesses and turns them into AHI function calls.
  By using the MMU to mark the page at $dff000 as invalid.
 
  Who knows, maybe that is that -40 Mhz hit Atheist is speaking of :-)
 
  Some similar non MMU solution could be made as small optional OS3/AROS68k patch or update, in "worse case scenario"?

Amithlon also had similar kind of solution
EXTERNAL LINK


Johannes Schäfer

Posts 47
05 Jun 2017 01:27


I found this discussion MMX vs. DSP from 1999 https://groups.google.com/forum/#!msg/comp.dsp/OEywTIoCauA/mTHDR7bqukAJ

DSP startet being obsolete due to MMX back in 1999. On the one hand  PentiumMMX solution was already faster and second developing for DSP was very special even back in the 90´s. I think today it would be much harder to find someone developing software for a DSP from the 90´s.

So we can say, we are lucky that Commodore didn´t invented DSP to the Amiga.




Cyber Gorf
(Needs Verification)
Posts 39/ 1
05 Jun 2017 01:47


My "Problem" here with banging the hardware directly or even via audio.device is that it is blocking.
  This is fine for games of course - mostly at least... well in some games it would be nice to listen to your own mp3-list and the game-soundeffects at the same time.
 
  While in Workbench doing some Amiga-typical multitasking, it is not Amiga-like at all to allow only one program to occupy all audio channels.
 
  People felt that back in the 90s and it was always considered as a shortcoming of the os.
  That's why these hacks exist, that redirect things to AHI - even if this is maybe a rather slow and unclean way.
 
  Maybe a more lightweight approach would be better?
  Some kind of mixer that gives us more audio channels, when and only when they are needed?
 
  I like the low-latency solution the genome-team came up with. It is described here with very comprehensive graphics:
  https://genode.org/documentation/release-notes/13.02#Low-latency_audio_output


Thierry Atheist

Posts 644
05 Jun 2017 03:40


Demo coders are definitely doing direct to Pamela audio, right? (I'm kind of asking, here.)


Vojin Vidanovic

Posts 770
05 Jun 2017 03:55


"So we can say, we are lucky that Commodore didn&#180;t invented DSP to the Amiga."
 
  I might be wrong in uderstanding that MMXs are just faster executed multimedia instructions that quicken some functions and tasks while burdening the CPU, just doing things faster in few selected areas, while DSP actually offloads CPU and can have more extensive programmible tasks like doing certaing things instead of CPU or in our case SAGA chipset (texturing, AI, sound ...).
 
  DSP on Classic: DOnt forget these were 030 days. As with Falcon, DSP could bring power at that time. Falcon with DSP could run Quake 2 engine
  EXTERNAL LINK  EXTERNAL LINK 
  There is an AGA port, for curious
  EXTERNAL LINK  and enhanced AROS i386 port
  EXTERNAL LINK 
  While I do understand a 1Ghz CPU with MMX could compute faster then Motorola 56 000 50-100Mhz, would not abandon DSP concept at all.
 
  a) First it can be a great multitasking core. If at any point,
  FPGA Apollo core cant grow in Mhz and second core cannot be implemented, adding a modern DSP offers additional offloading, better multitasking and more options for coders and could be seen as just another member of chipset. In direct FPGA modular design to memory and 080MMX it could aid greatly. It doesnt have to be complex design as old school Jaguars and 3DOs used to be, just 080, SAGA and an DSP. One of the options is to e.g. set a OS 3.0 Motorola FPU emulation until done in SAGA. I am sure different coders will find its merits.
 
  b) DSPs themselves have evolved and involved. When I say 96k instruction set I dont mean same hardware design and Mhz. Example is that high end FPGAs from same Altera/Intel include high end DSP/FPU
  https://www.altera.com/products/fpga/stratix-series/stratix-10/features.html#dsp
 
  That could be also a magic 3D chip/math operation e.g. in the way there was long long time ago a dedicated OpenGL calculations chip was a GlintMX or original 3Dfx Voodos. Example would be to pass all OpenGL to such "crucher" leaving the CPU alone, having apple and oranges. Or having some complex sound effects, as an example.
 
  It migh not be any part of standard, but lets say maybe of some Vampire special addition.
 
  I am not a tech guy, but seems that unlike current Altera Cyclone 3 our Vampires use, bit newer and higher in cost Aria series brings some "DSP blocks" of different use, but based on similar tech, bringing improvements to FPGA
  EXTERNAL LINK 
Also note that some AMD advanced arhitectures, dont just have integrated GPU. They offload CPU for video reproduction via dedicated hardware
EXTERNAL LINK  EXTERNAL LINK 
Its both "old" and "new" concept in multimedia, and is something
in 2D world Copper and Blitter did. We just have more complex audio and video tasks.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Jun 2017 10:22


Vojin Vidanovic wrote:

I am not a tech guy, but seems that unlike current Altera Cyclone 3 our Vampires use, bit newer and higher in cost Aria series brings some "DSP blocks"

The DSP blocks are used all over in the APOLLO MMX unit.

To give you some Information.
APOLLO 68080 is much more powerful than those Motorola DSP you were referring to.

Your post implies that a even a weak DSP could help to offload a strong CPU.
This is a misperception.
In real live this will not help but cause slowdowns a lot.

It should be very easy to understand this.


Kolbjørn Barmen
(Needs Verification)
Posts 219/ 2
05 Jun 2017 19:00


Gunnar von Boehn wrote:

  I like Eagle Player more in this regard.
  Eagle player puts a lot more focus on getting best Audio quality.
 

 
  Too bad the EagleAMP GUI engine doesn't work without installing dedicated render.library and guigfx.library for "68EC060", from seperate archives. Also, it uses mpega.library for playback of mp3, and it seems too slow for real-time playback.



Vojin Vidanovic

Posts 770
05 Jun 2017 21:19


" Too bad the EagleAMP GUI engine doesn't work without  ..."

Where did you get the 68EC060 files :-)

p.s. cpu really existed, and as 060 int, no fpu, no mmu code is ideal for current vampire. If you know of such optimized 060 and some AmigaOS libs or datatypes, let us know :-)


Henryk Richter
(Apollo Team Member)
Posts 128/ 1
05 Jun 2017 21:51


Kolbjørn Barmen wrote:

    Too bad the EagleAMP GUI engine doesn't work without installing dedicated render.library and guigfx.library for "68EC060", from seperate archives. Also, it uses mpega.library for playback of mp3, and it seems too slow for real-time playback.

What does a GUI plugin have to do with audio decoding and playback?

Besides, it's not my fault that you seem to be unaware of 68k variants beyond 68030. I've been playing MP3 at all supported bitrates in realtime over 20 years ago.

The intellectual level of your trolling is spiraling downwards.

posts 44page  1 2 3