New Universal Agnus 8372, 75 etc

[nonarkitten]

You know there seem to be three kinds of trolls in the Amiga community right now.

We have the feature creeps where nothing is ever good enough because in their mind it needs to compete with a modern PC. AGA isn't good enough, they need 32-channel 16-bit sound with 3D accelerated RTG and an 8 core, 4GHz CPU to back that up. Clearly their brain trust has failed them, because what they want is a PC and can't get out of their PC-envy/hate that Amigans suffered in the day to move on.

We have the luddites who want absolutely nothing new and grumble about any new feature. AGA sucks, ECS was fine. No one needs faster floppies. Upscaling is too hard. New is bad! NEW IS BAAAD!

And the have the Pi nazis who will replace every part in their Amiga with a Pi if they could but don't get that just running UAE on a Pi would be better. Everything must be a Pi or it is no good!

I'll try and watch my language but unless you're being constructive, could you kindly find a flesh cave of your own making and shove yourself into it?

[pandy71]

Originally Posted by nonarkitten

I'll try and watch my language but unless you're being constructive, could you kindly find a flesh cave of your own making and shove yourself into it?

lol - don't need to be mean... and i'm not against these features (even if some of them with such small FPGA seem to be not so realistic), twice faster MFM can be achieved currently just by adding MFM encoder/decoder so no software encoding/decoding required - just single "POKE" to set or clear bit - if you check currently available sample rates granularity and how close you can be to industry standard (32000, 44100, 48000 and associated 16000, 22050, 24000) or to UART standard baud rates (115200) i hope you will understand what i'm trying to say (NCO is just phase accumulator so no need dedicated PLL).

Once again you and kipper2k doing great and hard work and this is very appreciated - be well and good luck.

[Gorf]

Originally Posted by nonarkitten

And the have the Pi nazis who ....

... insist on Apfelstrudel?

[grelbfarlk]

I was just suggesting the Waveblaster header because:
It's incredibly simple to integrate
It's totally optional, but for people who want a nice sounding midi synth this is a pretty clean way of doing it
Doesn't require any support from you and your people
It wouldn't require any significant system resources

But I get feature creep

[QuikSanz]

Original specs look fine, leave it alone for now. Better, maybe l8r. now is good!!

[Promilus]

I'd say since initial design is done it would be best to wait a while for a "alpha test batch" to be distributed and tested. And then, eventually add feature list to "beta batch" which - at some point - might require pcb rework anyway.

[QuikSanz]

Works for me. Its a good start, get that and others correctly first then new stuff.

Chris

[kipper2k]

My thougts are to get the basics working, allow for updates via chip size usage and PCB design, Once a basic design is working then any additions wouldnt compound any errors that there may be.

[Wayne123]

I could really use one for my 3000, nice to see all the new hardware being created.

[QuikSanz]

@kipper2k,
Where should I expect the sale of new chips, your site? or another. Will keep looking.

Chris

[AJCopland]

Originally Posted by nonarkitten

In 16bpp mode, chunky mode will use a 4444 RGBV mode where the high 4-bits of each channel are independently controlled and the low four bits are the same for all three channels. This produces 65536 colours with 256 gradients.

How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.

If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.

Since we're hypothecising about 16-bit is there any reason to not support 5551 or 565 formats? Does it just not fit with how the hardware can be made to work?

This is not criticism by the way, I'm just trying to understand the idea

[lmimmfn]

Originally Posted by AJCopland

How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.

If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.

The V is Value from HSV, or Brightness. so each colour can have its brightness changed separately, similar to half bright but allowing configurable 4 bit brightness

[Romanujan]

Once all these Buffee replacement chips are ready, will it be possible to create a brand new ReAmiga 1200 with brand-new (no NOS) components only?

[nonarkitten]

Originally Posted by AJCopland

How do you get 65536 colours from 4444? I don't quite understand this one. I've used it as RGBA on console but there it give 12-bit (4096) colour with 16 steps of Alpha.

The fourth component is value, not alpha.

Originally Posted by AJCopland

If I've understood correctly you take that 12-bit RGB and then the other 4-bits would modify it somehow to get 65536. Sorry I just didn't understand the usage of the V channel.

So we have four bits per component; reg, green, blue and value. For example, if we have the 12-bit RGB colour $A37, this would look like:

R G B Bit
1 0 0  3
0 0 1  2
1 1 1  1
1 1 1  0

The value component adds low bits to all three channels, so if we then had say $A375, it would look like:

R G B Bit
1 0 0  7
0 0 1  6
1 1 1  5
1 1 1  4
-----
0 0 0  3
1 1 1  2
0 0 0  1
1 1 1  0
V V V

Or in 24-bit terms, the 16-bit RGBV colour $A375 becomes $A53575. Though sometimes I wonder if interleaving the bits wouldn't be more useful. Maybe I'll make a little C# program to vet these.

Originally Posted by AJCopland

Since we're hypothecising about 16-bit is there any reason to not support 5551 or 565 formats? Does it just not fit with how the hardware can be made to work?

In 555 RGB you can produce only 32 shades; with 16-bit RGBV, you can produce 256 shades. The eye is more sensitive to luminosity changes (hence why HDMI has chroma subsampling) and RGBV leverages this. If we totally went crazy, I'd say an 8-4-4 Lab or YCbCr would be even better, but that's a little too freaky for some people.

The NEOGEO used a similar scheme with 15-bits RGB and one value bit they called the "dark bit," giving it a near 666 RGB colour range. So that's an interesting compromised between 565 RGB and a 5551 RGBV -- if that were the same bit then anything made to use 565 wouldn't look TOO wrong in 5551... hmmm.

The disadvantage of this scheme is that it makes for less saturated colours (though more useful ones). For example, if we compress this down to a simple 4-bit palette we end up with:

$000 Black
$555 Dk Grey
$00A Blue
$55F Lt Blue
$0A0 Green
$5F5 Lt Green
$0AA Dk Cyan
$5FF Lt Cyan
$A00 Red
$F55 Pink
$A0A Purple
$F5F Lavender
$AA0 Gold
$FF5 Yellow
$AAA Lt Grey
$FFF White

Which if you squint, is really close to what we got with the C64 (except we're trading cyan for orange). But you'll notice there is no "pure red" -- you have "pink" at $F55 and "red" at $A00 but not $F00.

The advantage of this is that it interrupts the Amiga hardware pipeline less. I was actually thinking of maybe even having 8-bit be a 2222 RGBV for consistency. You can think of this as a type of colourspace compression where we're favouring luminosity over saturation, that's all.

Originally Posted by AJCopland

This is not criticism by the way, I'm just trying to understand the idea

Hope this helps.

[QuikSanz]

Originally Posted by nonarkitten

We plan to have Willoe address 16MB regardless and all of this is "DMA-able", that is, it can be read or written by any of the custom chips. It is useable for video, blitter objects, sprites, audio samples, disk buffers, etc., but only the first 2MB or less is directly accessible by the CPU.

If you install Xander, then you can have up to 2MB on all systems. If you then enable 4MB or 8MB of chip, then yes, that would cut into Zorro RAM as chip RAM is always contiguous (e.g., all 8MB would need $000000 to $7FFFFF).

I'm really a rookie here but does $7FFFFF leave enough for a PicassoIV? Must have 4 Meg!



Chris

[nonarkitten]

Originally Posted by QuikSanz

I'm really a rookie here but does $7FFFFF leave enough for a PicassoIV? Must have 4 Meg! Chris

No, you'd have to scale back to 4MB or 2MB of chip RAM.

[QuikSanz]

OK, so anything after 2 meg is in Zorro space. 4MB it is. When and where to buy?

Chris

[Bruce Abbott]

Originally Posted by pandy71

twice faster MFM can be achieved currently just by adding MFM **encoder/decoder** so no software encoding/decoding required

Yes, and it doesn't take any more bandwidth than DD MFM. But this is incompatible with trackdisk device so it would need its own driver.

I'm not a fan of HD format because the disks tend to be unreliable. We have better storage options for large files these days so the extra capacity isn't needed. With a PC floppy drive you can use HD disks in DD format by covering the HD detect hole, so the (relative) lack of DD disks isn't a problem.

if you check currently available sample rates granularity and how close you can be to industry standard (32000, 44100, 48000 and associated 16000, 22050, 24000) or to UART standard baud rates (115200) i hope you will understand what i'm trying to say (NCO is just phase accumulator so no need dedicated PLL).

I'm against adding 'improvements' where they aren't really needed.

Paula wasn't intended to be a studio quality audio device, so slight variations in playback frequency aren't important.

But why is 22050 an 'industry standard' anyway? It's half of 44.1kHz, which was chosen because at 3 samples per line it matches both PAL and NTSC video timing. Why is this important? Because digital audio was being recorded on video cassettes using the standard line by line helical format. This frequency was then used for audio CDs, and the submultiples of 11025 and later 22050 were used in the Sound Blaster card.

So in standard screen modes an 'enhanced' Paula could get exact 22050 playback by simply locking the sample rate to the video line frequency.

But what the Amiga really needs is a way of reproducing 16 bit audio more accurately and with less overheard than the so-called 14 bit mode. It would be nice if you could produce true 16 bit output by eg. interpreting each word as a single 16 bit sample. If the DAC can't do 16 bits then even 12 bits would be better than the 10 real bits of calibrated '14 bit' mode. Other possibilities include using 8 bits for applying volume to every sample, or an exponential mapping such as u-law.

When set to 115,200 the Amiga's baud rate clock is within 0.6%, which is fine. What the serial port really needs is a multi-byte receive buffer.

[nonarkitten]

Originally Posted by Bruce Abbott

I'm not a fan of HD format because the disks tend to be unreliable. We have better storage options for large files these days so the extra capacity isn't needed. With a PC floppy drive you can use HD disks in DD format by covering the HD detect hole, so the (relative) lack of DD disks isn't a problem.

That was a great way to get data errors. DD and HD don't have compatible media as SD and DD had. This is probably why it got a reputation for being "unreliable." On Mac and PC I never had an issue with HD floppies in HD drives.

Originally Posted by Bruce Abbott

I'm against adding 'improvements' where they aren't really needed.

... or supported.

Originally Posted by Bruce Abbott

Paula wasn't intended to be a studio quality audio device, so slight variations in playback frequency aren't important.

The shift from PAL to NTSC does bug me, but it's less about the note than it was the speed of music (50->60Hz is a bigger jump than 3.58MHz to 3.54MHz).

Originally Posted by Bruce Abbott

So in standard screen modes an 'enhanced' Paula could get exact 22050 playback by simply locking the sample rate to the video line frequency.

NTSC is 15.75kHz. Three scanlines would be 47.25kHz.
PAL is 15.625kHz. Three scanlines would be 46.875kHz.

Paula's timing is based on 3.5MHz ticks though (3546895 Hz PAL, 3579545 Hz NTSC) and 22050 would be 162 on NTSC making 22,096 Hz and 161 on PAL for 20,030 Hz. The shift from 22050 is probably undetectable to most people.

Originally Posted by Bruce Abbott

But what the Amiga really needs is a way of reproducing 16 bit audio more accurately and with less overheard than the so-called 14 bit mode. It would be nice if you could produce true 16 bit output by eg. interpreting each word as a single 16 bit sample. If the DAC can't do 16 bits then even 12 bits would be better than the 10 real bits of calibrated '14 bit' mode. Other possibilities include using 8 bits for applying volume to every sample, or an exponential mapping such as u-law.

When set to 115,200 the Amiga's baud rate clock is within 0.6%, which is fine. What the serial port really needs is a multi-byte receive buffer.

I agree on both points about the UART. UART is also very tolerant to clock drift, so 0.6% is fine, but the biggest show stopper to higher baud rates is the interrupt overhead for the 68000. A FIFO would be the biggest gain on UART if literally nothing else was done. Even a tiny 4-byte one.

I've been thinking about audio. Planned fixes
- three-state output now has 1.5 effective bits per cycle
- change to 13-bit accumulator to preserve sample quality
- 55kHz volume PWM is preserved for real "Amiga sound"
- pulse-density frequency is bumped from 3.5MHz to 7MHz
- LFSR added to sub-LSB for noise shaping and other fixes
- 56kHz mode without enabling Productivity Mode

There isn't a lot more we can do with Paula that will work with existing software. Anything beyond Paula is better to as something else entirely under AHI.

[Bruce Abbott]

Originally Posted by nonarkitten

That was a great way to get data errors.

I have tried it and it worked fine. However I prefer to use high quality DD disks, which is why I recently bought 3 boxes of Fuji DD disks from the US via eBay. 30 disks should last me a long time.

This is probably why it got a reputation for being "unreliable."

No. My experience with flaky HD disks was only on PC's (never needed to use them on the Amiga 'back in the day').

NTSC is 15.75kHz. Three scanlines would be 47.25kHz.
PAL is 15.625kHz. Three scanlines would be 46.875kHz.

I wondered how they got those numbers, now I see the issue. Digital audio was recorded to videotape only during active scan lines, not during the blanking period. This gets the correct 44.1kHz, but the frame has to be buffered to get continuous playback.

Paula's timing is based on 3.5MHz ticks though (3546895 Hz PAL, 3579545 Hz NTSC) and 22050 would be 162 on NTSC making 22,096 Hz and 161 on PAL for 20,030 Hz. The shift from 22050 is probably undetectable to most people.

Yep, close enough that it would be very hard to tell the difference (pitch change 0.2% NTSC, 0.1% PAL, much less than typical cassette tape player tolerances).

I've been thinking about audio. Planned fixes...

'Sounds' good. I look forward to hearing a demonstration.