d8sunch@dtek.chalmers.se (Christer Sundin) (03/28/91)
Ideas for a Super Paula:
I thought of improving Paula in two easy (?) ways.
Number one, add some logic to Paula so that you halve
the number of sound channels, but double the frequency
of the D/A conversion. I guess the sound DMA is only capable
of supplying Paula with 56 K words per second, that is
28 K bytes per second for four channels.
Number two, add two 16-bit D/A converters (This may not be
cheap). In this case, you have two 16-bit channels at 28 kHz,
or one at 56 kHz.
This way you will have four modes for Paula:
1. Four 8-bit channels, at 28 kHz
2. Two 8-bit channels, at 56 kHz
3. Two 16-bit channels, at 28 kHz
4. One 16-bit channels, at 56 kHz
Not bad, huh?
Opinions/ideas welcome!
...Chris
_ | Christer Sundin | d8sunch@dtek.chalmers.se |
// |----------------------------------------------------------------|
_ // Amiga | The sun is the same in a relative way, but you're older |
\X/ Forever | Shorter of breath and one day closer to death... (Pink Floyd) |
--
_ | Christer Sundin | d8sunch@dtek.chalmers.se |
// |----------------------------------------------------------------|
_ // Amiga | The sun is the same in a relative way, but you're older |
\X/ Forever | Shorter of breath and one day closer to death... (Pink Floyd) |bevis@en.ecn.purdue.edu (Jeff Bevis) (03/29/91)
I'm reposting this; I don't think the last try worked... (sorry if it's a clone) In article <1991Mar27.233751.24077@mathrt0.math.chalmers.se>, d8sunch@dtek.chalmers.se (Christer Sundin) writes: > >Ideas for a Super Paula: > >I thought of improving Paula in two easy (?) ways. >Number one, add some logic to Paula so that you halve >the number of sound channels, but double the frequency >of the D/A conversion. I guess the sound DMA is only capable >of supplying Paula with 56 K words per second, that is >28 K bytes per second for four channels. > >Number two, add two 16-bit D/A converters (This may not be >cheap). In this case, you have two 16-bit channels at 28 kHz, >or one at 56 kHz. > >This way you will have four modes for Paula: > >1. Four 8-bit channels, at 28 kHz >2. Two 8-bit channels, at 56 kHz >3. Two 16-bit channels, at 28 kHz >4. One 16-bit channels, at 56 kHz > >Not bad, huh? > >Opinions/ideas welcome! You asked for it. One of my big complaints has been the lack of improvement to the audio hardware. Of course, now, we've got folks complaining about both audio and video from the machine, so Commodore ought to be realizing that entirely new blow-away-the-neighborhood custom chips are finally in order. But, if we want to continue to improve the current chip set, these are the audio modifications I would have: Provide a means whereas the sprite DMA time may be reallocated, not for sprites, but for audio. Then, we've got 16 more bus cycles to play with per scan line, for a total of 20. Then, we could choose between sprites or audio DMA. When we choose audio, we'll get 40 bytes of DMA per scan line (~63 microseconds). With 20 audio DMA cycles/line, we could do the following neat stuff: 1. Increase the maximum sampling frequency of our existing four audio channels by a factor of five... Giving us a sampling rate of up to 158Khz per channel. Not all too useful, granted, but it gives us that forbidden range beyond 28Khz. 2. Increase the number of channels by a factor of 5. Instead of 4, we'd have 20. Now this would take a LOT of extra register space, but how cool! These channels would be bounded by the 31Khz physical limit as is now. (2 samples per scan line ~ 31Khz). Note that 20 channels means 10 on left and right. We needn't have 20 DACs in Paula for this (:-). Two would suffice by digitally summing the 10 data for each channel and outputting the result through a single 12-bit DAC (at each channel). 3. Using still bigger DACs, we could do 12-bit audio using a full word (discard the 4 msb's). So, with 20 cycles per line, we could get 20 samples. We want at least 2 samples/channel per line, so there's room for 10 channels of 12-bit audio (five per side). We'd need to have two 15-bit DACs for this. Maximum rate: 31Khz/channel. Or, we could get really sneaky and use all 16-bits of each word and have about 26 12-bit words/line. Also, we could increase the sampling frequency limit again by reducing the number of channels. This kind of change introduces all kinds of hardware dilemmas. If we've got, say, 16 possible audio channels instead of four, we'll want to have interrupts available for them. Not to mention DMA enable/disable. So, since there are only four bits in dmacon and intena/intreq, we'll need new registers for this. We'd need mode select bits, to disable sprite DMA, and many new sets of audio control registers with period, volume, length, and address data each. For higher sampling rates, we'll need to base audio sampling rates on a higher clock rate. And, for compatibility, we'll probably have to use a new pre-divider register for each channel. What a mess we can make! Ah, the ecstasy of dream... ------------------------------------------------------------------------------- "Three is never equal to four, except for very large values of three." ------------------------------------------------------------------------------- Jeff Bevis Purdue Univeristy School of Electrical Engineering bevis@ecn.purdue.edu Give me Amiga or nothing at all. ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------- "Three is never equal to four, except for very large values of three." ------------------------------------------------------------------------------- Jeff Bevis Purdue Univeristy School of Electrical Engineering
holgerl@amiux.UUCP (Holger Lubitz) (03/29/91)
In article <1991Mar27.233751.24077@mathrt0.math.chalmers.se> d8sunch@dtek.chalmers.se (Christer Sundin) writes: >Ideas for a Super Paula: And here are mine: What about panel control on every single channel ? Shouldn't be that much more complicated than the current chip design, and would allow to place the channels anywhere (hmm, register width limits there, but 255 positions between left and right would be ok, having a value of 128 for example point to the middle position), instead of the current two left and two right channels. Implementing 16-bit-Audio would indeed be fine, and having two channels of 16-bit at 28 kHz would allow the Amiga to play near CD-quality sound, but I would also be interested in having more channels at lower sampling rates. Why not have eight DMA sound channels as an option as well, reducing sampling rate to say 14 kHz ? Anyways: If there is an ECS Paula in the works, what I would like more than anything else is support for higher data transfer rates to the floppy drives. Say 300k for 5,25"-HD-Drives, 500k for 3,5"-HD-Drives (eliminating the need to halve the speed), and eventually also whatever these new ED-Drives need (the ones they build into the NeXT-stations). Any further suggestions ? Best regards, Holger
<LEEK@QUCDN.QueensU.CA> (03/30/91)
In article <holgerl.0587@amiux.UUCP>, holgerl@amiux.UUCP (Holger Lubitz) says: > >Anyways: If there is an ECS Paula in the works, what I would like more than >anything else is support for higher data transfer rates to the floppy >drives. Say 300k for 5,25"-HD-Drives, 500k for 3,5"-HD-Drives (eliminating >the need to halve the speed), and eventually also whatever these new >ED-Drives need (the ones they build into the NeXT-stations). A variable data rate floppy interface(with some FIFOs on it.) The variable data rate would allow one to read Mac disk using even standard Amiga DD floppies and allowed for future higher density floppies. >Best regards, >Holger K. C. Lee Elec. Eng. Grad. Student